libblockdev
libblockdev copied to clipboard
storaged-project
RFE: support for FS_IOC_SETFSLABEL
This ioctl will get and set labels on mounted filesystems. Currently f2fs, btrfs, xfs support it. https://man7.org/linux/man-pages/man2/ioctl_fslabel.2.html
Most useful would be GNOME Disks (and similar) being able to do file system label changes while the file system is mounted, in particular system root which can't be unmounted. But also generally leads to a better user experience, and is hopefully more maintainable.
We are currently using filesystem tools to set label (for example xfs_admin for XFS) so I'd expect these tools to support online label change using this ioctl. Unfortunately this is not the case with xfs_admin. I guess we could do that (or more precisely libblockdev could do that, we are currently working on moving as much of the filesystem management code as possible to libblockdev), but I really think btrfs, xfs and f2fs tools are the right place for this.
Unfortunately this is not the case with xfs_admin I mentioned it to @djwong (XFS maintainer) and he said it's an oversight that it was missed, xfs_io did get this enhancement. So I suspect it'll happen in a near future xfsprogs. @sandeen Let's see if my @'s work.
For btrfs it's btrfs filesystem label and it can be directed to either a block device if unmounted or to a mountpoint if mounted.
Those ioctls looks interesting, however their use should be placed in lower layers below UDisks. Getting a label should be a blkid task propagating the value further in the udev database.
As for setting the label this could be a nice complement to the specific filesystem tools as called from libblockdev. Furthermore for a generic and not fully supported filesystem type in libblockdev this might be a way to go. Or, in case the tools are not installed, this might work instead. In any case, this issue should be moved to https://github.com/storaged-project/libblockdev.
@vojtechtrefny: do you plan to make use of this in relation to #621? Either as a fallback or as a first step prior to calling the fs-specific tool. Given the wide range of kernels our code is running on, we need to support both cases.
I plan to take a look at this, but probably not as a part of #621, it could be a separate change.