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