>> 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. > Diagnostic information is useful, but is it useful to store on disk?
In many cases storing it in core is good enough, though I'm sure there are at least some cases where it needs to go to disk. > It seems to me that for the investigation you describe, systems such > as ktrace, dtrace, and filemon would be more appropriate than the > [acm]time of the inode. Possibly. I'm not familiar with dtrace or filemon, but ktrace cannot produce that information unless the relevant processes were being traced when they last did I/O. [acm]times allow after-the-fact investigation without needing to leave the processes traced during routine operation. > However, I suppose they monitor processes, rather than inodes, There's that too. >> Is one inode update per minute enough to be a significant issue? > It means the disk must continue spinning and, e.g., will continue to > draw power from a laptop battery to do so, even when the system is > functionally idle. Aren't there lots of things that already do that? Some of them can be suppressed by various mechanisms (eg, nodevmtime mounts); one possibility is to use the same or similar mechanisms here. Another is to address it some other way. In the case of postfix, the first thing that occurs to me is to make the FIFO path a symlink into a tiny mfs mount dedicated to the purpose; updating the mtime of an inode in a ramdisk is very fast, very cheap, and does not require keeping a disk spinning. Depending on whether the relevant support has bitrotted, it could even be turned into a direct mount of a ramdisk whose root inode is a FIFO rather than a directory. /~\ 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
