From: "Austin S. Hemmelgarn" <firstname.lastname@example.org> To: Chris Murphy <email@example.com> Cc: Andrei Borzenkov <firstname.lastname@example.org>, Adam Borowski <email@example.com>, Btrfs BTRFS <firstname.lastname@example.org> Subject: Re: updatedb does not index /home when /home is Btrfs Date: Mon, 6 Nov 2017 14:44:53 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAJCQCtTy8FqbgJwvC86+7fZBTAgP8bnnH4rz1xpj4dAVuBWSCQ@mail.gmail.com> On 2017-11-06 13:35, Chris Murphy wrote: > On Mon, Nov 6, 2017 at 6:51 AM, Austin S. Hemmelgarn > <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2017-11-06 19:44 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-04 0:15 Chris Murphy 2017-11-04 4:49 ` Adam Borowski 2017-11-04 6:26 ` Andrei Borzenkov 2017-11-04 7:05 ` Adam Borowski 2017-11-04 18:27 ` Andrei Borzenkov 2017-11-04 18:55 ` Chris Murphy 2017-11-04 19:37 ` Nicholas D Steeves 2017-11-05 8:01 ` Andrei Borzenkov 2017-11-06 13:51 ` Austin S. Hemmelgarn 2017-11-06 18:35 ` Chris Murphy 2017-11-06 19:44 ` Austin S. Hemmelgarn [this message] 2017-11-05 7:47 ` Fixed subject: updatedb does not index separately mounted btrfs subvolumes Duncan 2017-11-05 14:02 ` Chris Murphy 2017-11-06 0:27 ` Peter Grandi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: updatedb does not index /home when /home is Btrfs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).