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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060809140349.GE13474@goober>
Date:	Wed, 9 Aug 2006 07:03:49 -0700
From:	Valerie Henson <val_henson@...ux.intel.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Akkana Peck <akkana@...llowsky.com>,
	Mark Fasheh <mark.fasheh@...cle.com>,
	Jesse Barnes <jesse.barnes@...el.com>,
	Chris Wedgwood <cw@...f.org>, jsipek@...sunysb.edu,
	Al Viro <viro@....linux.org.uk>
Subject: Re: [RFC] [PATCH] Relative lazy atime

On Sat, Aug 05, 2006 at 06:22:50AM -0700, Arjan van de Ven wrote:
> Christoph Hellwig wrote:
> >Another idea, similar to how atime updates work in xfs currently might
> >be interesting:  Always update atime in core, but don't start a
> >transaction just for it - instead only flush it when you'd do it anyway,
> >that is another transaction or evicting the inode.
> 
> this is sort of having a "dirty" and "dirty atime" split for the inode I 
> suppose..
> shouldn't be impossible to do with a bit of vfs support..

This is certainly another possibility.  There may be other uses for
the idea of a half-dirty inode.

However, one thing I want to avoid is an event that would cause the
build-up and subsequent write-out of a big list of half-dirty inodes -
think about the worst case: grep -r of the entire file system,
followed by some kind of memory pressure or an unmount.  Would we then
flush out a write to every inode in the file system?  Ew. (This is
worse than having atime on because with full atime, the writes would
be spread out during the execution of the grep -r command.)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ