On Mon, Jun 30, 2008 at 11:57:31PM +0100, Jamie Lokier wrote: > > FWIW, this is exactly the same case as getting the extent map of a > > directory data (I use xfs_bmap all the time for this) - you know > > where the blocks are, but without completely decoding the directory > > structure you have no idea where inside that map a given entry is. > > There's a thought. What does "offset" mean for directory data and > FIEMAP? (And xattrs, but let's ignore that, it's less important). > > What's the appropriate thing to return for FIEMAP on a directory, on a > filesystem which doesn't store directories as a blob of data with > contiguous offsets? > > E.g. directory offsets (readdir) do mean something, but there's no > guarantee that directory offsets 0..N-1 corresponds with extents > covering N bytes exactly. > > Would it return extent data similar to a file with large holes? Yes. FIEMAP is not in the business of interpreting individual directory entries. You can look at the Ocfs2 or ext4 patches for examples, but directory extents are simply treated like file extents. In the case of Ocfs2, where small directories can be stored inside of the inode meta data, the blob is returned as a single extent, with the appropriate descriptor flags set (FIEMAP_EXTENT_DATA_INLINE in particular). --Mark -- Mark Fasheh -- 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
