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]

Message-ID: <20060805222247.GQ29686@ca-server1.us.oracle.com>
Date:	Sat, 5 Aug 2006 15:22:47 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	Chris Wedgwood <cw@...f.org>
Cc:	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, 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?

I don't see why not, but I figure it'd be good to make sure there's some
concensus on that.

If that is in fact the case, OCFS2 could do the same thing as XFS and
update disk only when we're going there for some other reason. The only
thing that we would have to add on top of that is a disk write when we're
dropping a cluster lock and the inode is still 'atime-dirty'. 
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@...cle.com
-
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/