Re: [RFC] [PATCH] Relative lazy atime

[Bill Davidsen <davidsen@tmr.com>]

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
>> nodiratime?
> 
> 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@tmr.com>
   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.