On 4/19/11 3:11 AM, Yongqiang Yang wrote: > On Tue, Apr 19, 2011 at 3:45 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> On Tue, Apr 19, 2011 at 02:53:20PM +0800, Yongqiang Yang wrote: ... >>> I think there are 2 ways to provide a definite definition for FIEMAP >>> for all filesystems: >>> >>> 1. FIEMAP returns extent state on disk. >>> 2. FIEMAP returns extent both in memory and on disk. >> >> You are *not listening*. There is no #2. FIEMAP returns the extent >> state _on disk_ at the time of the call. If you want it to reflect >> the in-memory state at the time of the call (for data or metadata), >> you *must* use the the SYNC flag to convert that in-memory state to >> on-disk state, which FIEMAP then reports just fine. > > Sorry for being dense. > > I think delayed extent is an exception. because it is not on the disk. > > Yongqiang. I don't think you're being dense, I think that the interface specification is just messed up. By including flags for both unwritten and delalloc in the interface, we have hopelessly intertwined on-disk and in-memory state. If you preallocate 1M and then do a buffered IO to that same range without a sync, and then a fiemap, what on earth should the interface return? Writing the first part of that testcase is simple but I have no idea what the correct behavior is. (FIEMAP_EXTENT_UNWRITTEN|FIEMAP_EXTENT_DELALLOC) ? that makes no sense. But no other combination of flags makes sense to me either, unless we get into tortured redefinitions of what "delalloc" means. And if we can't say what it -should- return.... well, too bad for coreutils. :( -Eric -- 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
