Theodore Tso wrote: > > FIEMAP_EXTENT_READ_ENCODED > > FIEMAP_EXTENT_WRITE_ENCODED > > If some application which wishes to use FIEMAP really wants to know > whether it's safe to write to an extent while the fs is unmounted, we > can add that flag later --- but I'm not that sure we really want to go > there. I agree. If it were ever added, it would have the opposite sense to FIEMAP_EXTENT_ENCODED: set would mean "can write". Sounds messy and suggests the sense of FIEMAP_EXTENT_ENCODED should be reversed so that _set_ means safe to read - effectively "not safe unless filesystem explicitly says it is". But it's functionally adequate, not a real bike shed colour clash :-) > Do you have a use in mind for this interface where this would be > useful? Barely imaginable uses: boot loader, BIOS-stage device tester or similar logging to a preallocated file, or a userspace benchmark testing direct block device access to a preallocated file. It's not something I'm interested in, just that it's barely conceivable, and I only thought of it when Chris mentioned shared data blocks. So no. I just wanted to clarify, because on most filesystems you _can_ write to the data blocks safely, and that's an assumption that Joe Obscure Boot Loader Hacker (who isn't familiar with modern filesystems) might be tempted by. One more thing, then: How can you safely use !(flags & FLAG_EXTENT_ENCODED) anyway in userspace code which is filesystem-independent? What tells you that the data isn't moved after calling FIEMAP and before unmounting, by unrelated activity on the filesystem? So should filesystems also set FLAG_EXTENT_ENCODED if there is any chance the data will move without any explicit operation on that file, even though the data itself is stored unencoded in data blocks? -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
