On 11.02.19 г. 11:43 ч., Carlos Maiolino wrote: > Hi. > > A discussion has been started on another thread [1], with the idea of extending > FIEMAP ioctl interface, to also report the device id where the extents being > reported are physically located. I've started to work on the extension, but, > before I spend time implementing it, I'd rather start a discussion to ensure > it's really feasible or just a waste of time in pursuing it. > > The whole context, can be found in the thread [1], more specifically in the > discussion started on patch 9, here [2]. > > About the proposal: > > - The general idea, is to provide a way for FIEMAP ioctls to return the device > id where each extent is physically located. > - This is particularly useful for those filesystems where the file extents are > located on a different block device other than that associated with the > superblock , for example, btrfs using multiple devices, and XFS when using a > real-time device. > > Achieving this is relatively easy, using one of the __u32 fe_reserved fields in > struct fiemap_extent, to create a new field (__u32 fe_device), which can be used > for two purposes, based on two new FIEMAP_EXTENT_ flags : > > - FIEMAP_EXTENT_DEVICE: which will indicate the fiemap_extent.fe_device contains > the major/minor numbers of the block device where the specific extent is > located > > - FIEMAP_EXTENT_COOKIE (of _EXTENT_PRIVATE), which indicates the > fiemap_extent.fe_device will contain a special meaning depending on the fs. > Such flag sounded interesting for distributed filesystems, which could use > this field for example, to specify each node of the cluster (or whatever other > name is defined by the specific fs) that specific extent is located. Who decides which flag is set? Do you intend for the default behavior to be FIEMAP_EXTENT_DEVICE which could be overridden by FIEMAP_EXTENT_COOKIE? IMHO a more becoming name could be FIEMAP_EXTENT_DEV_PRIVATE or PRIVATE_DEV. > > > As mentioned before, implementing it, looks not that difficult, considering such > reserved fields are not to be touched by userspace, and using one of the new > fields won't break any current userspace application which doesn't understand > the new data. > But still, things which are worth to discuss is if such information (the > physical location of the extents) is something that should be exported to > userspace or not. > > Any comments if this is something worth to implement or not, are welcome. > > Cheers > > [1] https://www.spinics.net/lists/linux-fsdevel/msg136559.html > [2] https://www.spinics.net/lists/linux-fsdevel/msg136568.html >
