linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@fusionio.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Subvolumes and /proc/self/mountinfo
Date: Tue, 19 Jun 2012 19:49:19 -0400	[thread overview]
Message-ID: <20120619234919.GA4102@shiny> (raw)
In-Reply-To: <4FDFCA43.2070407@zytor.com>

On Mon, Jun 18, 2012 at 06:39:31PM -0600, H. Peter Anvin wrote:
> I'm trying to figure out an algorithm from taking an arbitrary mounted
> btrfs directory and break it down into:
> 
> <device(s), subvolume, subpath>
> 
> where, keep in mind, <subpath> may not actually be part of the mount.

Do you want an API for this, or is it enough to wander through /dev/disk
style symlinks?

The big reason it isn't here yet is because Kay had this neat patch to
blkid and udev to just put all the info you need into /dev/btrfs (or
some other suitable location).  It would allow you to see which devices
belong to which filesystems etc.

> 
> /proc/self/mountinfo seems to have some of that information, however, it
> does not appear to distinguish between non-default subvolumes and
> directories.  At the same time, once I have mounted a subvolume I see
> its name in the root btrfs directory even if I didn't access it.
> 
> Questions, thus:
> 
> a. Are subvolumes always part of the "root" namespace?  If so, is it the
> mounted root, the default subvolume, or subvolume 0 which always exposes
> these other subvolumes?  Are there disambiguation rules so that if I
> have /btrfs/root/blah and "blah" is both a subvolume and a directory (I
> presume that can happen?)

subvolumes may become disconnected from the root namespace.  In this
case we can find it just by the subvol id, and mount it into an
arbitrary directory.

> 
> b. Are there better ways (walking the tree using BTRFS_IOC_TREE_SEARCH?)
> to accomplish this than using /proc/self/mountinfo?

Not yet, but I'm definitely open to adding them.  Lets just hash out
what you need and we'll either go through Kay's stuff or add ioctls for
you.

-chris

  parent reply	other threads:[~2012-06-19 23:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19  0:39 Subvolumes and /proc/self/mountinfo H. Peter Anvin
2012-06-19 14:22 ` Calvin Walton
2012-06-19 23:35   ` H. Peter Anvin
2012-06-20  1:27     ` Fajar A. Nugraha
2012-06-20  8:21     ` Hugo Mills
2012-06-19 23:49 ` Chris Mason [this message]
2012-06-20  0:03   ` H. Peter Anvin
2012-06-20 13:34     ` Chris Mason
2012-06-20 15:59       ` H. Peter Anvin
2012-06-20  0:39   ` Helmut Hullen
2012-06-20  1:16     ` cwillu
2012-06-20  3:22       ` H. Peter Anvin
2012-06-20  6:31         ` Fajar A. Nugraha
2012-06-20 23:43           ` H. Peter Anvin

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=20120619234919.GA4102@shiny \
    --to=chris.mason@fusionio.com \
    --cc=hpa@zytor.com \
    --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).