Re: [RFC] [PATCH] Relative lazy atime

From: Bill Davidsen
Date: Thu Aug 10 2006 - 13:23:46 EST

Valerie Henson wrote:
On Sat, Aug 05, 2006 at 09:01:47PM -0600, Matthew Wilcox wrote:
On Sat, Aug 05, 2006 at 04:28:29PM -0700, dean gaudet wrote:
you can work around mutt's silly dependancy on atime by configuring it with --enable-buffy-size. so far mutt is the only program i've discovered which cares about atime.
For the shell, atime is the difference between 'you have mail' and 'you
have new mail'.

I still don't understand though, how much does this really buy us over

Lazy atime buys us a reduction in writes over nodiratime for any
workload which reads files, such as grep -r, a kernel compile, or
backup software. Do I misunderstand the question?

I mentioned lazy atime about a year ago, and have played with a patch to do what I (personally) had in mind. My thinking is that for files the atime is almost always used in one of two ways, as part of system administration to see if a file is being used, and to sort files by atime to identify recently accessed files, such as the one you read just before the weekend.

So in that light, I proposed that a filesystem might have a mount option such that atime was only updated when an open or close was done on the file. In many cases this will both reduce inode writes and still preserve information "current enough" to be useful, which is unavailable with noatime. And since noatime is thought useful as a attribute, lazy atime probably would be, as well.

Bill Davidsen <davidsen@xxxxxxx>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at