linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: pg@btrfs.list.sabi.co.UK (Peter Grandi)
To: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Fixed subject: updatedb does not index separately mounted btrfs subvolumes
Date: Mon, 6 Nov 2017 00:27:07 +0000	[thread overview]
Message-ID: <23039.44123.933173.628778@tree.ty.sabi.co.uk> (raw)
In-Reply-To: <pan$94157$844c1b67$c8d5af52$b34db269@cox.net>

>> The issue is that updatedb by default will not index bind
>> mounts, but by default on Fedora and probably other distros,
>> put /home on a subvolume and then mount that subvolume which
>> is in effect a bind mount.

> <gripe-mode: inaccurate subject lines>

> So the issue isn't /home being btrfs (as you said in the
> subject), but rather, it's /home being an explicitly mounted
> subvolume, since btrfs uses bind-mounts internally for
> subvolume mounts.

That to me seems like rather improper terminology and notes, and
I would consider these to be more appropriate:

* There are entities known as "root directories", and their main
  property is that all inodes reachable from one in the same
  filesystem have the same "device id".
* Each "filesystem" has at least one, and a Btrfs "volume" has
  one for every "subvolume", including the "top subvolume".
* A "root directory" can be "mounted" on a "mount point"
  directory of another "filesystem", which allows navigating
  from one filesystem to another.
* A "mounted" root directory can be identified by the device id
  of '.' being different from that of '..'.
* In Linux a "root directory" can be "mounted" onto several
  "mount point" directories at the same time.
* In Linux a "bind" operation is not a "mount" operation, it is
  in effect a kind of temporary "hard link", one that makes a
  directory aliased to a "bind point" directory.

Looking at this:

  tree#  tail -3 /proc/mounts                                                                                                                                            
  /dev/mapper/sda7 /fs/sda7 btrfs rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=5,subvol=/ 0 0
  /dev/mapper/sda7 /fs/sda7/bind btrfs rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=431,subvol=/= 0 0
  /dev/mapper/sda7 /fs/sda7/bind-tmp btrfs rw,nodiratime,relatime,nossd,nospace_cache,user_subvol_rm_allowed,subvolid=431,subvol=/=/tmp 0 0

  tree#  stat --format "%3D %6i %N" {,/fs,/fs/sda7}/{.,..} /fs/sda7/{=,=/subvol,=/subvol/dir,=/tmp,bind,bind-tmp}/{.,..} 
  806      2 ‘/.’
  806      2 ‘/..’
   23  36176 ‘/fs/.’
  806      2 ‘/fs/..’
   26    256 ‘/fs/sda7/.’
   23  36176 ‘/fs/sda7/..’
   27    256 ‘/fs/sda7/=/.’
   26    256 ‘/fs/sda7/=/..’
   2b    256 ‘/fs/sda7/=/subvol/.’
   27    256 ‘/fs/sda7/=/subvol/..’
   2b    258 ‘/fs/sda7/=/subvol/dir/.’
   2b    256 ‘/fs/sda7/=/subvol/dir/..’
   27 344618 ‘/fs/sda7/=/tmp/.’
   27    256 ‘/fs/sda7/=/tmp/..’
   27    256 ‘/fs/sda7/bind/.’
   26    256 ‘/fs/sda7/bind/..’
   27 344618 ‘/fs/sda7/bind-tmp/.’
   26    256 ‘/fs/sda7/bind-tmp/..’

It shows that subvolume root directories are "mount points" and
not "bind points" (note that ‘/fs/sda7/=/subvol’ is not
explicitly mounted, yet its '.' and '..' have different device
ids), and that "bind points" appear as if they were ordinary
directories (an unwise decision I suspect).

Many tools for UNIX-like systems don't cross "mount point"
directories (or follow symbolic links), by default or with an
option, but will cross "bind point" directories as they look
like ordinary directories.

For 'mlocate' the "bind point" directories are a special case,
handled by looking up every directory examined in the list of
"bind point" directories, as per line 381 here:

https://pagure.io/mlocate/blob/master/f/src/bind-mount.c#_381

      parent reply	other threads:[~2017-11-06  0:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04  0:15 updatedb does not index /home when /home is Btrfs 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
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 [this message]

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=23039.44123.933173.628778@tree.ty.sabi.co.uk \
    --to=pg@btrfs.list.sabi.co.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).