Posted Aug 9, 2007 9:09 UTC (Thu) by addw
Parent article: Once upon atime
Part of the reason that atime causes disk traffic is that if a file is read many times (each read satisfied from cache) an atime update will be generated for each time the file is read. So you get multiple disk writes to same the inodes over and over.
Why not defer the inode updates, then you might get one set of disk writes either when the file system is unmounted or when it becomes idle or at scheduled intervals (eg every 1/2 hour). In practice many systems do not open large numbers of files, but repeatedly access a subset time and again. The usual exception to this is the backup program.
From my point of view: if the system dies before it writes the atime out then not a lot is lost; maybe a spurious ''you have mail'' when I login again.
Memory usage is the primary cost as the in-memory inode needs to be kept longer than it normally would be. This could be ameliorated by having a new strucut (device, inode#, atime) to store this info if we trash the in-memory inode.
to post comments)