On Sunday 25 May 2008, Christoph Hellwig wrote: Thanks for doing this Mark ;) > On Sat, May 24, 2008 at 05:01:48PM -0700, Mark Fasheh wrote: > > * FIEMAP_FLAG_HSM_READ > > If the extent is offline, retrieve it before mapping and do not flag > > it as FIEMAP_EXTENT_SECONDARY. This flag has no effect if the file > > system does not support HSM. > > Given that there's no HSM support in mainline this should not be added. > It'll be useful once we add proper HSM support, though :) > The HSM flag doesn't hurt, and it allows the people actually shipping hsm patches to use fiemap without extending the api themselves. Reserving the flag isn't a bad idea. > > * FIEMAP_FLAG_LUN_ORDER > > If the file system stripes file data, this will return contiguous > > regions of physical allocation, sorted by LUN. Logical offsets may not > > make sense if this flag is passed. If the file system does not support > > multiple LUNs, this flag will be ignored. > > A LUN doesn't make any sense in filesystem context. That's a > scsi-centric acronym that doesn't even make sense in a scsi-centric > filesystem universe because a LUN can of course contain multiple > partitions. It's also extremly ill-defined when using volume managers. > > There's also no filesystems that actually support a single file on > multiple device in mainline, the only filesystem that supports multiple > data devices at all (XFS) requires each file to be on a single device. > > Once we have a filesystem with real multiple data device support like > btrfs or a future XFS version we can worry about this and defined > a different ioctl for it. > For btrfs I would return the logical extents via fiemap (just like the file were on lvm) and make btrfs specific ioctls for details about where the file actually lived. fiemap alone isn't a great way to describe raid levels or complex storage topologies. To include physical information I would also have to encode the raid level used and information about all the devices the data is replicated on (raid1/10) -chris -- 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
