Hi, On Mon, Feb 11, 2019 at 01:29:57PM +0200, Nikolay Borisov wrote: > > > 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. > The idea is: - If none of the flags are set, the fe_device field is ignored by FIEMAP infrastructure. - If FIEMAP_EXTENT_DEVICE is set, and _COOKIE (or _PRIVATE) IS NOT, then, the fe_device is the major/minor dev_t of the block device holding the extent. - If both flags ARE SET, the fe_device holds a value that only the specific filesystem (and maybe its users) can properly interpret. > > > > > > > > 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 > > -- Carlos
