linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: mount command now shows subvol and subvolid
Date: Tue, 1 Sep 2015 07:17:53 +0000 (UTC)	[thread overview]
Message-ID: <pan$76183$87074bc$e26a0ee$dfbc2e3a@cox.net> (raw)
In-Reply-To: 20150831134517.GQ11834@twin.jikos.cz

David Sterba posted on Mon, 31 Aug 2015 15:45:17 +0200 as excerpted:

> On Sun, Aug 30, 2015 at 11:17:44AM -0600, Chris Murphy wrote:
>> Does anyone know when this changed? Maybe it's a 4.2 thing... anyway
>> it's very much welcome!
> 
> And another "side effect" is that /proc/self/mountinfo will report the
> mounted subvolume, even if it was an implicit mount of non-toplevel
> subvolume.

Another very nice side effect, likely accidental, but still very nice... 
is how subvol= ends up being reported for bind-mounts.

I don't use subvolumes here, but I do use multiple separate btrfs, so 
subvolid=5, subvol=/ for all of them, would be technically correct, if 
not particularly useful.  But while the subvolid=5 is indeed constant 
(and actually useful given the following), subvol= turns out to be rather 
more helpful than the / that would normally be expected.

I have a number of bind-mounts.  Formerly mount's output for these wasn't 
particularly helpful, since I ended up with a number of...

/dev/sda5 on <mountpoint> ...

... lines (/dev/sda5 being my rootfs), for instance.  The mountpoint is 
listed, but exactly what part of the filesystem is being bind-mounted 
there isn't (tho /proc/self/mountinfo does contain it).  While the 
filesystem component (/etc/bind, for instance) actually being bind-
mounted was generally what I was interested in, it wasn't actually 
displayed, and could only be indirectly derived from the mountpoint,
by looking up the mountpoint in fstab, for instance, or by using /proc/
self/mountinfo instead of the mount output or /proc/mounts.

With the new subvolume thing, despite the fact that as I said I don't use 
subvolumes so subvolume=/ would be technically correct, the subvol= now 
points at the particular component of the filesystem being bind-mounted 
at the given mountpoint.

So while I still have a bunch of /dev/sda5 on <mountpoint> lines, now the 
subvolume= bit actually tells me what's bind-mounted there, as in (sda5 
is /, sda4 is /var/log)...

/dev/sda5 on /mnt/cbind/etc/bind type btrfs (...,subvol=/etc/bind)
/dev/sda4 on /mnt/cbind/var/log/named type btrfs (...,subvol=/named)

Again, technically the subvol is actually / in both cases, since I don't 
use subvols.  And the subvolid is indeed 5, as expected.  But the 
actually reported subvol=/etc/bind is *so* much more helpful than the 
subvol=/ that I might have expected. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2015-09-01  7:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-30 17:17 mount command now shows subvol and subvolid Chris Murphy
2015-08-31  6:15 ` Omar Sandoval
2015-08-31 13:45 ` David Sterba
2015-09-01  7:17   ` Duncan [this message]
2015-09-01 10:24     ` Karel Zak

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='pan$76183$87074bc$e26a0ee$dfbc2e3a@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).