WIP: btrfs multidisk volume support #838
Conversation
|
(the first two commits are from #819, need to merge and rebase, along with an additional change I was planning) |
Each member device has a superblock which contains
If the effective mount command is by UUID, i.e. /dev/disk/by-uuid/ then I think this problem can be ignored because the kernel is expected to deconflict, with btrfs:harden agaist duplicate fsid on scanned devices. |
That's exactly the kind of information that should be exposed via udev attribute in the first place.
The But yes, I think the |
tbzatek
force-pushed
the
btrfs-multivolume
branch
from
20b4bc7
to
76a58b6
Compare
|
Pushing this back to |
|
Structure of an active mount looks to be exposed on |
I forgot to mention the sysfs stuff, sorry. The problem is this info isn't available in sysfs until the file system is mounted. I'm not sure how this works for mdadm raid, whether or how udev figures out how many devices there are, but maybe the kernel can be enhanced to expose limited info like "number of devices" in sysfs even if they aren't all yet available or mounted? Is that useful? Related: |
tbzatek
changed the title
|
FYI the Perhaps rewriting |
I must've overlooked the sysfs stuff the first time I was looking for any suitable information there. Or perhaps I didn't have any active mounts back at that time... I guess for the purposes of identifying exact block devices involved in a mounted filesystem this is sufficient, for the non-mounted scenario not all information are necessary at that point and the The purpose for the mounted scenario is to deny potentially destructive operations on the For the non-mounted scenario callers are free to destroy any component of a multidisk btrfs filesystem as they wish
Thanks for pushing this upstream. I think my former kdave/btrfs-progs#302 request looks obsolete now, still need to check whether we have all the information we need before closing that one. |
This should be working properly now with uevent synthetic tagging in use.
Queried in the udev database.
This should be a common function to check whether the filesystem is a traditional one, device number based, or whether it is a filesystem of a different concept, based e.g. on 'volumes' such as btrfs, and to indicate that any filesystem matching should be done some different way, e.g. by filesystem UUID.
…ed filesystems For filesystems with concept of 'volumes' the device number of an active mount often doesn't match the real backing block device. A different approach must be taken to match the mount with a block device. The generic ID_FS_UUID udev attribute looks like a good candidate and it seems to be widely used nowadays. For the moment this approach is only used for btrfs devices. The downside of such approach is grouping of all devices carrying the particular attribute value under one volume, no matter whether they're actually attached to an active mount or if it's just a copy (duplicate UUIDs caused by full byte copy of a device).
This extends the on-disk mount state file structure with filesystem UUID if available or requested. This is an initial support that might be further extended to consider other block devices in the group (filesystem volume or an active mountpoint). For now the cleanup takes a more conservative approach in such case.
This returns a list of UDisksObjects that are part of the multidisk volume the current UDisksFilesystem interface points to.
… multidisk volume Wired for the Mount() and Unmount() methods so far this will trigger additional uevents to the rest of the block devices that form the particular "volume".
This will ensure the properties on all block objects that form a multi-disk btrfs volume are properly updated.
tbzatek
force-pushed
the
btrfs-multivolume
branch
from
76a58b6
to
29815d0
Compare
|
Some more ideas:
|
|
What is the status of this PR? |
I'm not sure, but I do think because of it's size(is it a dozen pages?) it should be scrapped. Also this PR doesn't address the parent issue leaving every other user of libblkid(util-linux) to also implement a solution leading to duplication of code... So not only is the patch large it causes an even greater burden to FOSS as a whole. There is a patch, it's about 200 lines, to libblkid that fully addressed the issue for me. util-linux/util-linux#1382 (comment) It's so small I won't bother with a PR, the commit messages alone would delete more time than the patch. |
Not entirely abandoned yet no free time to work on this. With the invention of bcachefs along with established multi-volume capable filesystems like btrfs, f2fs and zfs, this will need to be taken more holistically to bring good enough abstraction for unique device identifiers. Lots of work, not enough time to work on. |
This adds basic support for btrfs multidisk volumes. Changes are done in a general approach, supporting primary identifiers other than the traditional unix block device numbers (
dev_t, major:minor). For btrfs such primary identifier becomes a udevID_FS_UUIDstring, other filesystems are TBD but relatively easy to add (e.g. f2fs). Decision which approach to use is currently based on filesystem type. As a result this forms a virtual group of block devices carrying the particular identifier inside the daemon that are updated together. For simplicity this grouping is denoted a volume or a filesystem volume.This however brings some caveats for this limited set of filesystems:
As this primarily affects mount points and mount operations only (and the
UDisksStatemachinery in the background), the rest of the functionality remains available without major changes. I.e. block object representation doesn't change, operations on theorg.freedesktop.UDisks2.Blockinterfaces are still available for the particular volume components, etc. As long as theID_FS_USAGE=filesystemudev property is exposed on such block devices there's no point for breaking any existing functionality. And I certainly believe filesystem authors were fully aware of consequences by presenting this attribute.This partly fixes #802 by denying multiple mounts for a given volume, no matter on which actual block object the
org.freedesktop.UDisks2.Filesystem.Mount()method is called. Theorg.freedesktop.UDisks2.Filesysteminterface properties should now be updated consistently across all objects for a given volume.btrfs subvolume mounting (#768) is still broken at this point, this needs to be handled along with allowing multiple mounts in general, for any filesystem.
I'm still not 100% sure this is the right approach and whether further iterations of this design should follow or not. My attempt was to fix https://gitlab.gnome.org/GNOME/gvfs/-/issues/519 in a sane way to prevent creating new mounts as a result of non-matching device number against an active mount.
Resolves #802