On Oct 29, 2007 17:11 -0700, Mark Fasheh wrote: > On Mon, Oct 29, 2007 at 04:13:02PM -0600, Andreas Dilger wrote: > > > Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode > > > blocks. > > > > Hmm, but part of the issue would be how to request the extra data, and > > what offset it would be given? One could, for example, use negative > > offsets to represent metadata or something, or add a FIEMAP_EXTENT_META > > or similar, I hadn't given that much thought. > > Well, fe_offset and fe_length are already expressed in bytes, so we could > just put the byte offset to where the inline data starts in there. fe_length > is just used as the length allocated for inline-data. > > If fe_offset is required to be block aligned, then we could add a field to > express an offset within the block where data would be found - say > 'fe_data_start_offset'. In the non-inline case, we could guarantee that > fe_data_start_offset is zero. That way software which doesn't want to care > whether something is inline-data (for example, a backup program) or not > could just blidly add it to fe_offset before looking at the data. Oh, I was confused as to what you are asking. Mapping in-inode data is just fine using the existing interface. The byte offset of the data is given, and the "FIEMAP_EXTENT_NO_DIRECT" flag is set to indicate that it isn't necessarily safe to do IO directly to that byte offset in the file (e.g. tail packed, compressed data, etc). I was thinking you were asking how to map metadata (e.g. indirect blocks). Cheers, Andreas -- Andreas Dilger Sr. Software Engineer, Lustre Group Sun Microsystems of Canada, Inc. - 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
