On 2013-09-03, at 6:11 AM, David Sterba wrote: > This flag was not accepted when fiemap was proposed [2] due to lack > of in-kernel users. Btrfs has compression for a long time and we'd > like to see that an extent is compressed in the output of 'filefrag' > utility once it's taught about it. > > [1] http://article.gmane.org/gmane.comp.file-systems.ext4/8871 > [2] http://thread.gmane.org/gmane.comp.file-systems.ext4/8870 > > +#define FIEMAP_EXTENT_DATA_COMPRESSED 0x00000040 /* Data compressed by fs > + * Sets EXTENT_ENCODED */ If the data is compressed, I think that just setting a flag in the fiemap_extent structure is not enough. It should also distinguish between the logical extent length and the physical extent length, by adding something like the fe_log_length field: struct fiemap_extent { __u64 fe_logical; /* logical offset in bytes for the start of * the extent from the beginning of the file */ __u64 fe_physical; /* physical offset in bytes for the start * of the extent from the beginning of the disk */ __u64 fe_length; /* physical length in bytes for this extent */ __u64 fe_log_length;/* logical length in bytes (DATA_COMPRESSED) */ __u64 fe_reserved64; __u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */ __u32 fe_reserved[3]; }; I'm a bit indecisive on whether the existing fe_length should be the physical length (which is what filefrag is reporting for the existing compressed files), or if it should be the logical length. For uncompressed files they would be the same, except fe_log_length is currently always zero. I don't think it makes sense to ever have an allocated extent with a logical length of zero, so tools could easily distinguish this case (without the DATA_COMPRESSED flag). Without this separation for compressed files, it isn't clear to the user if the file is sparse with holes all over it, even in the presence of the DATA_COMPRESSED flag. Also, it isn't clear for tools like tar or cp what parts of the file they should copy. Cheers, Andreas -- 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
