Re: updatedb does not index /home when /home is Btrfs

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-11-06 13:35, Chris Murphy wrote:
> On Mon, Nov 6, 2017 at 6:51 AM, Austin S. Hemmelgarn
> <ahferroin7@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.