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]
Date:	Fri, 16 Aug 2013 13:21:24 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 0/5 v2] add extent status tree caching

On Tue, Aug 13, 2013 at 09:04:59AM -0400, Theodore Ts'o wrote:
> On Mon, Aug 12, 2013 at 10:21:45PM -0500, Eric Sandeen wrote:
> > 
> > Reading extents via fiemap almost certainly moves that metadata into
> > kernel cache, simply by the act of reading the block device to get them.
> 
> Well, if the file system has an extent cache.  It certainly will end
> up reading the pages involved with the extents into the buffer and/or
> page cache (depending on how the file system does things).

Of course. ext4 has an extent cache, so you're agreeing that FIEMAP
will populate the extent cache for the use case google has, right?

> > I see Dave's point that we _do_ have an interface today to read
> > all file extents into cache.  We don't mark them as particularly sticky,
> > however.
> > 
> > This seems pretty clearly driven by a Google workload need; something you
> > can probably test.  Does FIEMAP do the job for you or not?  If not, why not?
> 
> If you are using memory containers the way we do, in practice every
> single process is going to be under memory pressure.  See previous
> comments I've made about why in a cloud environment, memory is your
> most precious resource.

<snip>

Sure, we know all that. But you haven't answered the question being
asked which was whether FIEMAP can acheive what you need. You've
already admitted it can populate the extent cache for ext4, so
there's little else that is needed to pin the extents is reads in a
range in the cache. Just one flag...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ