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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
