Re: [RFC][PATCH 0/5] Fiemap, an extent mapping ioctl

[Christoph Hellwig <hch@infradead.org>]

On Wed, May 28, 2008 at 10:09:31AM -0600, Andreas Dilger wrote:
> ... but I don't think it should necessarily be _required_ to return a
> real "dev_t" (major, minor) device.  For network filesystems this is
> meaningless.  If it is possible for FIEMAP_EXTENT_NET to signal that the
> device is not a local/physical device (where a dev_t has no meaning),
> and simply allow an enumeration [0, 1, 2, ...] of the logical devices
> then I think this is reasonable.  The mapping of logical devices to
> servers is available separately with a Lustre-specific ioctl.
> 
> This passes more information for filesystems that have local devices
> while not breaking the functionality for network filesystems and could
> be used as an efficient replacement for lilo's use of FIBMAP.

A dev_t actually means something for the only in-tree users of
this interface, so there's no point making this interface worse for
some long-term out of tree code.  And it's not like you simply can't
allow multiple anonymous blockdevices for your networked filesystems
similar to the one used for st_dev already.

> For RAID1/10 you can return multiple logical->physical extent mappings
> for the same logical range of the file with different "device" IDs.  You
> could do the same for RAID5 returning each of the data and parity chunks
> with "NO_DIRECT" if desired (maybe only on the parity extent, or don't
> return the parity extent at all).  The spec does not require that the
> returned extents be non-overlapping.

Umm, no.  That's just make the interface too complicated.  I can bet
with your that userspace programmers will generally only test their code
with simple filesystems and hell will break lose when they get these
multiple ranges.  Especially as that's a very unnatural interface.