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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
