public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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