On 2017-11-06 13:35, Chris Murphy wrote:
On Mon, Nov 6, 2017 at 6:51 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
This brings to mind another 'feature' of BTRFS that I came across recently,
namely that subvolumes that aren't explicitly mounted still show up as mount
points according to how most CLI tools differentiate what's a mount point.
In particular, the st_dev field in stat() results for the subvolume differs
from the containing directory, and the f_fsid field in statvfs() results for
the subvolume differs from the containing directory (a side effect of the
differing st_dev field, which is part of what's used to calculate f_fsid on
Linux), which means the only way to know if something actually is a mount
point is to make this check, and then verify it in /proc/mounts or
/proc/self/mountinfo.
That particular 'feature' means that GNU find, xargs, and du will never
cross subvolume boundaries if you tell them to stay on one filesystem, and
some other tools may misidentify where things are mounted.
Elsewhere I brought up that mountinfo gives bogus subvol= information
that conflicts with the subvolid= information, when doing bind mounts
of directories on Btrfs. Trivially reproduced in my home directory:
[chris@f26h ~]$ mkdir directory1
[chris@f26h ~]$ mkdir directory2
[chris@f26h ~]$ sudo mount -B directory2 directory1
[chris@f26h ~]$ mount:
/dev/nvme0n1p8 on /home type btrfs
(rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/home)
/dev/nvme0n1p8 on /home/chris/directory1 type btrfs
(rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/home/chris/directory2)
The first mount item is correct, there is a subvolume home with
subvolume ID of 257, mounted at /home.
The second mount item considers directory2 a subvolume (wrong), with
subvolid 257 (kinda right, it's on subvolid 257, but kinda wrong, it
is not itself a subvolume).
Yeah, thankfully the only stuff I personally need to worry about this
for doesn't care whether it's a regular mount, a bind mount, or an
explicitly mounted subvolume, just that's it's actually a real mount
point, not an implicit subvolume mount.
Ideally, all of this needs to be looked at eventually and cleaned up
such that things are reasonably sane. I understand why st_dev changes
for each subvolume (they all show an inode number of 256, so things
might break if st_dev matched too), but the rest of this is just
unnecessary fallout from that.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
