> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B