https://bugs.kde.org/show_bug.cgi?id=427092
--- Comment #20 from Chris Murphy <bugzi...@colorremedies.com> --- >Possibly such functionality belongs in udisksd, if it's the service being >requested to do the mount. A possibly complicating factor is that it's legit to mount a Btrfs file system more than one time, e.g. mount -o subvol=accounting /dev/vdc1 /mnt/accounting mount -o subvol=photos /dev/vdc1 /mnt/photos In effect, all btrfs mounts are bind mounts, even without this option because it's always implied. A mount without -o subvol means "use the default subvolume" which out of the box is an unnamed subvolume created at mkfs time, and can't be renamed or deleted. It's also called the "top-level" of the file system. The subvolume mounted by default can be changed using 'btrfs subvolume set-default', which leads to the case of how do you get back to this invisible "top-level" file system subvolume? These are equivalents: mount -o subvol=/ /dev/vdc1 /mnt mount -o subvolid=5 /dev/vdc1 /mnt mount -o subvolid=0 /dev/vdc1 /mnt This is why in the mount command at the top of ' solid-hardware5 details, mounted multiple' attachment, you see 'subvolid=5,subvol=/' Btrfs is a file system of btrees, they each have a number, and the original design made the file btree id 5. And then soon after it was aliased to 0 to make it easier to remember I guess. Anyway, all subsequently created subvolume, and subvolume snapshots, are additional file btrees. Hence all of them can be mounted in this fashion, depending on layout preference. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout But that doesn't really answer the question how to handle this case. All the desktops have some variation on this problem, which suggests a need for a common way to handle it if possible. -- You are receiving this mail because: You are watching all bug changes.
