From: Goffredo Baroncelli <kreijack@gmail.com>
To: Josef Bacik <josef@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: change how we mount subvolumes
Date: Fri, 4 Dec 2009 19:49:11 +0100 [thread overview]
Message-ID: <200912041949.12320.kreijack@alice.it> (raw)
In-Reply-To: <20091204173827.GB5962@localhost.localdomain>
Hi Josef
On Friday 04 December 2009, Josef Bacik wrote:
> This work is in preperation for being able to set a different root as the
> default mounting root.
>
> There is currently a problem with how we mount subvolumes. We cannot
currently
> mount a subvolume of a subvolume, you can only mount subvolumes/snapshots of
the
> default subvolume. So say you take a snapshot of the default subvolume and
call
> it snap1, and then take a snapshot of snap1 and call it snap2, so now you
have
>
> /
> /snap1
> /snap1/snap2
>
> as your available volumes. Currently you can only mount / and /snap1, you
> cannot mount /snap1/snap2. To fix this problem instead of passing
subvol=<name>
> you must pass in subvol=<treeid>, where <treeid> is the tree id that gets
spit
> out via the subvolume listing you get from the subvolume listing patches
> (btrfsctl -l). This allows us to mount /, /snap1 and /snap1/snap2 as the
root
> volume.
>
Nice feature.
But only for clarification purpose I have to correct you: the only limit of
the "subvol=" mount option is that the "volume name" or "snapshot name" have
to be under the root of the "btrfs" filesystem (or if you prefer under the
root of the "." volume).
So:
- a subvolume created under / may be mounted using the subvol= mount option
- a subvolume created under a directory *can't* be mounted using the subvol=
mount option
- a subvolume created under a directory and moved under "/" *may* be mounted
using the subvol= mount option
- a snapshot of a subvolume created under / may be mounted using the subvol=
option
And so...
(As side note: a subvol may be renamed/moved with a simple "mv" command.)
In fact the "subvol=" mount option related code, search in the root of the
btrfs a subvolume/snapshot named as required, then mount it. Doesn't matter if
it is a snapshot of a subvolume or where it is originally created.
In any case I like your idea.
BR
G.Baroncelli
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
next prev parent reply other threads:[~2009-12-04 18:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 17:38 [PATCH] Btrfs: change how we mount subvolumes Josef Bacik
2009-12-04 18:49 ` Goffredo Baroncelli [this message]
2009-12-07 0:52 ` TARUISI Hiroaki
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=200912041949.12320.kreijack@alice.it \
--to=kreijack@gmail.com \
--cc=josef@redhat.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