linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Andrei Borzenkov <arvidjaar@gmail.com>,
	Chris Murphy <lists@colorremedies.com>,
	Adam Borowski <kilobyte@angband.pl>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: updatedb does not index /home when /home is Btrfs
Date: Mon, 6 Nov 2017 11:35:53 -0700	[thread overview]
Message-ID: <CAJCQCtTy8FqbgJwvC86+7fZBTAgP8bnnH4rz1xpj4dAVuBWSCQ@mail.gmail.com> (raw)
In-Reply-To: <78727726-c7fc-c645-d805-ef746a81b715@gmail.com>

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).


-- 
Chris Murphy

  reply	other threads:[~2017-11-06 18:35 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 [this message]
2017-11-06 19:44                 ` Austin S. Hemmelgarn
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 \
    --in-reply-to=CAJCQCtTy8FqbgJwvC86+7fZBTAgP8bnnH4rz1xpj4dAVuBWSCQ@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=ahferroin7@gmail.com \
    --cc=arvidjaar@gmail.com \
    --cc=kilobyte@angband.pl \
    --cc=linux-btrfs@vger.kernel.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).