linux-kernel - Re: [patch] implement smarter atime updates support

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:	Sun, 05 Aug 2007 13:22:36 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jakob Oestergaard <jakob@...hought.net>,
	Jeff Garzik <jeff@...zik.org>, miklos@...redi.hu,
	akpm@...ux-foundation.org, neilb@...e.de, dgc@....com,
	tomoki.sekiyama.qu@...achi.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-mm@...ck.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	nikita@...sterfs.com, trond.myklebust@....uio.no,
	yingchao.zhou@...il.com, richard@....demon.co.uk, david@...g.hm
Subject: Re: [patch] implement smarter atime updates support

On Sun, 2007-08-05 at 21:04 +0100, Alan Cox wrote:
> O> you might want to add
> > 
> > 	/* 
> > 	 * if the inode is dirty already, do the atime update since
> > 	 * we'll be doing the disk IO anyway to clean the inode.
> > 	 */
> > 	if (inode->i_state & I_DIRTY)
> > 		return 1;
> 
> This makes the actual result somewhat less predictable. Is that wise ?
> Right now its clear what happens based on what user sequence of events
> and that this is easily repeatable.

I can see the repeatability argument; on the flipside, having a system
of "opportunistic atime", eg as good as you can go cheaply, but with
minimum guarantees has some attraction as well. For example one could
imagine a system where the inode gets it's atime updated anyway, just
not flagged for writing back to disk. If it later undergoes some event
that would cause it to go to disk, it gets preserved...

otoh that's even more unpredictable since VM pressure could drop this
update early.

For the dirty case, such drawbacks don't exist; it's just one more step
of "when we can cheaply".

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
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/