On Tue, Oct 07, 2008 at 09:28:54AM -0400, Christoph Hellwig wrote: > On Tue, Oct 07, 2008 at 02:24:36PM +0100, Jamie Lokier wrote: > > Ok, without getting in the way any more :-) it would be good to > > clarify in the description whether !(flags & FIEMAP_EXTENT_ENCODED) > > means only reading is allowed, or if it means writing over the data > > blocks is safe too. > > > > Just so that filesystems will know whether to set the flag for blocks > > which can be read but not written. This may include tail-merged > > blocks. > > I think writing to a filesystem without fs assistance is always a bad > idea. And yes, we should add this to the description. Ok, how about this? * FIEMAP_EXTENT_ENCODED This extent does not consistant of plain filesystem blocks but is encoded (e.g. encrypted or compressed). Reading the data in this extent via I/O to the block device will have undefined resuts. Note that it is *always* undefined to try to update the data in-place by writing to indicated location without the assistance of the filesystem, or accessing the data using the information returned by the FIEMAP interface while the filesystem is mounted. In other words, user applications may only read the extent data via I/O to the block device while the filesystem is unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is clear; user applications must not try reading or writing to the filesystem via the block device under any other circumstances. - Ted -- 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
