Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Brad Boyer <flar@allandria.com>]

On Mon, Jun 30, 2008 at 04:07:41PM -0700, Mark Fasheh wrote:
> 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).

What would you expect as reasonable behavior for an FS type that
doesn't have distinct storage for directories? On HFS and HFS+, the
directory information is completely synthetic based on the parent
ID of each file. A directory has no actual data dedicated to it 
other than the basic metadata that would be in the inode in ext3,
and readdir just walks the catalog tree and finds all the entries
that say they have the directory you want as a parent. They are
sorted that way, so it's not as bad as it sounds for performance.

Would it be reasonable for a filesystem like this to just say that
a directory has no extents at all? You can open a directory and
seek to an offset, but that doesn't logically map to any place
on the disk. Is this going to cause problems?

	Brad Boyer
	flar@allandria.com