Thread (32 messages) 32 messages, 5 authors, 2013-08-16

Re: [PATCH 0/5 v2] add extent status tree caching

From: Theodore Ts'o <tytso@mit.edu>
Date: 2013-08-16 14:39:23

On Fri, Aug 16, 2013 at 01:21:24PM +1000, Dave Chinner wrote:
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...
I thought you were asking a different question, which is whether we
could just use FIEMAP and not try to soft-pin the extents in the
cache.  And the answer to that is no.

If the argument is that you think it's better to allocate an extra bit
to FIEMAP rather than allocate a new ioctl code --- shrug.  I'm not
sure why you're making such a big deal about that; it's not like we're
short on ioctl code points.  I'm willing to do this, although if we
keep on getting API bikeshedding, my fallback position is to just
implement this as an ext4-specific ioctl and call it a day.

I am curious whether any other file system is actually going to
implement this or not, though.  If everyone else is convinced that
their file system is so wonderful that they don't need this, or this
is just a wierdo Google use case, I'm not sure why we're spending so
much time bikeshedding the APi.

						- Ted
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help