[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fifo and [acm]time
>> 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
> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |