On Wed, Sep 10, 2008 at 05:49:34AM -0700, Mark Fasheh wrote: > * FIEMAP_FLAG_XATTR > If this flag is set, the extents returned will describe the inodes > extended attribute lookup tree, instead of it's data tree. So does this actually make sense for any filesystem but XFS? Still seems like a not too useful option for a highlevel generic interface. > __u32 fe_device; /* device number for extent */ As sayd before please kill thise one. It doesn't make any sense at all for any merged or near mainline FS. It'd be an utterly stupid lustre-specific hack that still doesn't make much sense. > * FIEMAP_EXTENT_NO_BYPASS > Direct access to the data in this extent is illegal or will have > undefined results. Huh? What is direct access? Direct access as in bypassing the filesystem and writing to the blockdev directly always has undefined results. > * FIEMAP_EXTENT_SECONDARY > The data for this extent is in secondary storage (e.g. HSM). If the > data is not also in the filesystem, then FIEMAP_EXTENT_NO_BYPASS > should also be set. No HSM in mainline, so please drop it. We can add it once we get HSM support. > * FIEMAP_EXTENT_NET > - This will also set FIEMAP_EXTENT_NO_BYPASS > The data for this extent is not stored in a locally-accessible device. Doesn't make any sense currently, please drop. > * FIEMAP_EXTENT_DATA_COMPRESSED > - This will also set FIEMAP_EXTENT_NO_BYPASS > The data in this extent has been compressed by the file system. Add once we have users for it. > * FIEMAP_EXTENT_DATA_ENCRYPTED > - This will also set FIEMAP_EXTENT_NO_BYPASS > The data in this extent has been encrypted by the file system. > > * FIEMAP_EXTENT_NOT_ALIGNED > Extent offsets and length are not guaranteed to be block aligned. > > * FIEMAP_EXTENT_DATA_INLINE > This will also set FIEMAP_EXTENT_NOT_ALIGNED > Data is located within a meta data block. > > * FIEMAP_EXTENT_DATA_TAIL > This will also set FIEMAP_EXTENT_NOT_ALIGNED > Data is packed into a block with data from other files. > > * FIEMAP_EXTENT_UNWRITTEN > Unwritten extent - the extent is allocated but it's data has not been > initialized. This indicates the extent's data will be all zero if read > through the filesystem but the contents are undefined if read directly from > the device. > > * FIEMAP_EXTENT_MERGED > This will be set when a file does not support extents, i.e., it uses a block > based addressing scheme. Since returning an extent for each block back to > userspace would be highly inefficient, the kernel will try to merge most > adjacent blocks into 'extents'. -- 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
