Automatic remount with `-o subvolid=5`?
Opened this issue · 8 comments
Hi! Is there any reason why btdu does not just try to remount the filesystem of given path with -o subvolid=5?
i. e. can we just do this? https://github.com/intelfx/bin/blob/master/wrappers/btdu
Two main reasons:
-
It's not clear where the mount point directory should be created, and how to guarantee that it is cleaned up. (Maybe the answer is a private mount namespace. I see that wrapper is using the same idea.)
-
One of the goals of btdu is to help users understand how btrfs works. I have seen many situations where users were unaware that their volume contained more subvolumes than were visible from the default mount configuration. Guiding them towards mounting the top-level subvolume by hand helped them identify and correct the problem, instead of just turning one problem into another ("what's eating my space" -> "how do I see / delete the thing eating my space").
Yes, creating a private, non-persistent mount namespace is an obvious answer.
One of the goals of btdu is to help users understand how btrfs works
But once the user understands that, it just becomes a huge annoyance (so the goal of educating the user becomes opposed to the goal of actually helping the user, unless the only goal of btdu is to educate).
Yes, this becomes a philosophical question. Should the tool cater to its average user, or to the user who is using it the most?
But once the user understands that, it just becomes a huge annoyance
Maybe I'm missing something. Why would it be a huge annoyance?
Personally, I have the top-level subvolumes always mounted (along with the purpose-specific subvolumes). I don't know why you wouldn't do that if you were a btrfs power user.
Considering that power users have a simple solution here (a script like the one above, or just keep the top-level subvolume mounted), I think I would lean towards keeping the status quo.
I'm one of those power users that always has subvolid 5 mounted ro (in my case at /mnt/root/real_root) but I always forget to pass the path of it to btdu. Some way of detecting this and automatically using the root subvol mount for the path specified would be nice but not necessary.
Personally, I have the top-level subvolumes always mounted (along with the purpose-specific subvolumes). I don't know why you wouldn't do that if you were a btrfs power user.
Quite the opposite, I believe it's a pretty bad practice.
It opens the root subvol to accidental manipulation (for example, I would never want to mistype a command and end up damaging my snapshots), clutters up mount/df/findmnt output, and has a chance of confusing other tools and GUI environments. There might also be security implications (I don't see any, but then again I was never part of a red team).
And even then, it's just an annoyance to have to remember and type in a special path to the root subvol mountpoint when all you want is e. g. btdu /.
Perhaps a right balance could be struck by adding an optional flag, e. g. -R/--remount? The didactic purpose of not having this behavior by default could be preserved/reinforced by e. g. adding a suitably ominous warning to the option's help text and/or the man page, for example:
> WARNING: DO NOT USE THIS OPTION UNLESS YOU UNDERSTAND THE IMPLICATIONS OF DOING SO.
If btdu only needs the mount point to run the INO_PATHS ioctl, that could be replaced by TREE_SEARCH emulation to resolve paths to filenames. LOGICAL_INO and TREE_SEARCH_V2 only require an open fd somewhere on the filesystem, and CAP_SYS_ADMIN privilege, so there would be no need for the root of subvolid 5 to be accessible.
For deleting files it's a bit harder because the path is required, but it could be done by finding out the filesystem paths for all the current mountpoints and mapping them to subvol/inode. Then when resolving a path for deletion, if one of the existing mount points is found during the search toward the root of the tree, that mount point can be used instead of the remainder of the path to the deleted object. A user wouldn't be able to delete anything that's not mounted.
There would be some extra problems working that way (what if the user mounted a subvol ro? What if mount points change while btdu runs?). btrfs-progs already tries to do that for some utilities (particularly btrfs ins log) and when it fails it makes the tools unusable.
Maybe the namespace is the easier thing to do (either in btdu or outside), since it doesn't require changing anything else.
OK, I'm convinced. Will accept a patch which adds unshare+mount, behind a switch at first, then default in a later version.
One small complication is that btdu currently shows the absolute userspace path for objects, which implies that it's working on a mounted filesystem. That would need to be either removed or made conditional on that the object is accessible via some mount point (as per @Zygo's suggestion).