Re: [RFC] [PATCH] Relative lazy atime

[dean gaudet]

On Sat, 5 Aug 2006, David Lang wrote:

> On Sat, 5 Aug 2006, Mark Fasheh wrote:
> 
> > On Sat, Aug 05, 2006 at 11:36:09AM -0700, Chris Wedgwood wrote:
> > > should it be atime-dirty or non-critical-dirty? (ie. make it more
> > > generic to cover cases where we might have other non-critical fields
> > > to flush if we can but can tolerate loss if we dont)
> > So, just to be sure - we're fine with atime being lost due to crashes,
> > errors, etc?
> 
> at least as a optional mode of operation yes.
> 
> I'm sure someone will want/need the existing 'update atime immediatly', and
> there are people who don't care about atime at all (and use noatime), but
> there is a large middle ground between them where atime is helpful, but
> doesn't need the real-time update or crash protection.

i can't understand when atime is *ever* reliable... root doing backups 
with something like rsync will cause atimes to change.  (and it can't 
save/restore the atime without race conditions.)

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.

also -- i wasn't aware that xfs tried to do a better job with atime
updates... i'm not sure it's really that effective.  i've got a
busy shell/mail/web server, and here's a typical 60s sample with
noatime,nodiratime on xfs:

Device:    rrqm/s wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda          0.00   0.77 13.72 25.94   418.34   328.72    18.84     2.21   55.75   3.63  14.40

and a typical 60s sample with atime,diratime:

sda          0.07   0.58 15.82 35.87   472.13   412.52    17.12     0.70   13.56   3.54  18.30

that's been my experience in general... an extra 15 to 20% iops required 
to maintain atime... just for mutt...  no thanks :)

(btw there's nvram underneath sda, so the await change isn't too 
surprising.)

-dean

p.s. lazyatime sounds like a nice hack to make mutt work too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/