linux-kernel - Re: [RFC] [PATCH] Relative lazy atime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 5 Aug 2006 16:28:29 -0700 (PDT)
From:	dean gaudet <dean@...tic.org>
To:	David Lang <dlang@...italinsight.com>
cc:	Mark Fasheh <mark.fasheh@...cle.com>, Chris Wedgwood <cw@...f.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Dave Kleikamp <shaggy@...tin.ibm.com>,
	Christoph Hellwig <hch@....de>,
	Valerie Henson <val_henson@...ux.intel.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Akkana Peck <akkana@...llowsky.com>,
	Jesse Barnes <jesse.barnes@...el.com>, jsipek@...sunysb.edu,
	Al Viro <viro@....linux.org.uk>
Subject: Re: [RFC] [PATCH] Relative lazy atime

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/