From: "H. Peter Anvin" <hpa@zytor.com>
To: Chris Mason <chris.mason@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Subvolumes and /proc/self/mountinfo
Date: Tue, 19 Jun 2012 17:03:49 -0700 [thread overview]
Message-ID: <4FE11365.3010802@zytor.com> (raw)
In-Reply-To: <20120619234919.GA4102@shiny>
On 06/19/2012 04:49 PM, Chris Mason wrote:
> 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.
>
I want an algorithm, it doesn't have an API per se. I would really like
to avoid relying on blkid and udev for this, though... that is pretty
much a nonstarter.
If the answer is to walk the tree then I'm fine with that.
> 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.
OK, so it sounds like the best thing is actually to record the subvolume
*number* (ID) where (in my case) Syslinux is installed. This is actually
a good thing because the fewer O(n) strings I have to stick into the
boot block the better.
>> 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.
Well, I'd be interested in what Kay's stuff actually does. Other than
that, I would suggest adding a pair of ioctls that when executed on an
arbitrary btrfs inode returns the corresponding subvolume and one which
returns the path relative to the subvolume root.
-hpa
next prev parent reply other threads:[~2012-06-20 0:03 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
2012-06-20 0:03 ` H. Peter Anvin [this message]
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=4FE11365.3010802@zytor.com \
--to=hpa@zytor.com \
--cc=chris.mason@fusionio.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.