Re: fifo and [acm]time

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> On ufs (and tmpfs and perhaps others), reading from or writing to a
> fifo updates its [acm]time [...]

> Note that the same [acm]time updates do not apply to sockets.

Aside from whether this is a good idea, this difference may make sense.

A FIFO is a single shared object; multiple opens result in multiple
references to a single FIFO.

You don't say whether the socket case is SOCK_STREAM or SOCK_DGRAM
sockets.

For SOCK_STREAM, a socket in the filesystem is more like a cloning
device: a connection established using it as a rendezvous point results
in new sockets, distinct from the socket corresponding to the
filesystem entry (though one of them is derived from it).  It is these
new sockets that the I/O occurs on and whose [acm]time would logically
be updated (if they had [acm]times, which they don't, because they
don't have [iv]nodes).

For SOCK_DGRAM, the above argument does not apply.  As a matter of
theory, read()/recv()/etc on such a socket should update the atime and
write()/send()/etc should update the mtime (and, of course, in each
case the ctime as well).  (I/O on the peer socket, the one that doesn't
have a filesystem entry, should not do anything of the sort, because
that socket doesn't have any [iv]node to update the [acm]time of.)
Pragmatically speaking, it's not clear to me that there's enough value
in either stance to make it worth changing whichever behaviour the
implementation happens to provide.

> And what applications would ever rely on the [acm]time of a fifo?

The only value I can see in the [acm]time of either a FIFO or an
AF_LOCAL socket "file" is to see when the relevant software last did
anything with it.  This is less a matter of an application proper using
the timestamp and more one of a human who's investigating something
looking for relevant (or possibly-relevant) data.

> One consequence of this is that in a vanilla NetBSD install, Postfix
> triggers disk I/O every minute when master tickles the pickup daemon
> by writing to the fifo /var/spool/postfix/public/pickup.

Is one inode update per minute enough to be a significant issue?
(Sure, there will be cases where it is enough to matter.  But are the
common enough that it's worth doing anything to NetBSD in consequence,
or are they outliers that call for per-system custom tuning?  I can
think of at least one approach which likely would address this problem,
in cases where it _is_ A problem, already, and that's with no more than
a minute or so of thought.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B