Re: [RFC] [PATCH] Relative lazy atime

From: dean gaudet
Date: Sat Aug 05 2006 - 19:26:09 EST


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/