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: <20060806001306.GR29686@ca-server1.us.oracle.com>
Date:	Sat, 5 Aug 2006 17:13:06 -0700
From:	Mark Fasheh <mark.fasheh@...cle.com>
To:	David Lang <dlang@...italinsight.com>
Cc:	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, Aug 05, 2006 at 04:06:47PM -0700, 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.
Well, it certainly doesn't sound like XFS is making this sort of guarantee.

Another method I've seen file systems use is to only update atime if the
difference between current time and the current inode atime is greater than
some timeout value. I'm not a huge fan of that approach as it seems less
predicatble than Val's, and doesn't (theoretically) preserve performance
like the XFS approach.

That said, it's not like OCFS2 doesn't have to care just because other file
systems don't but I don't see much complaining about their methods.


> 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.
For OCFS2, the performance hit of 'immediate' atime updates could be
considerable. It's essentially turning a bunch of read only cluster locks
into exclusive ones, and forcing a disk update. This means that other nodes
who have locks on the object would have to invalidate their cache. The node
doing the update will be have to flush it's journal before giving the lock
up, incurring additional cost.

We could certainly give OCFS2 an "immediate atime" mode, but maybe that
could be done as a different mount option? Say, "immatime"? That way the
default is to get the large middle ground. Those who want more performance
could use 'noatime', and those concerned with absolute 100% correctness of
atime in the event of a crash could use the new option.
	--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/