From: C Anthony Risinger <firstname.lastname@example.org>
To: Chris Ball <email@example.com>
Subject: Re: default subvolume abilities/restrictions
Date: Wed, 19 May 2010 09:55:19 -0500 [thread overview]
Message-ID: <AANLkTimMAJ7WOgerdxp-yxlRvT9SaREnumqFFQ85VeOL@mail.gmail.com> (raw)
On Wed, May 19, 2010 at 9:20 AM, Chris Ball <firstname.lastname@example.org> wrote:
> =A0 > moving along to a question... can the default subvolume be
> =A0 > swapped/removed/renamed/popped/shifted?
> I think "btrfs subvolume list; btrfs subvolume set-default <id> <path=
> does what you need.
> - Chris.
maybe i'm missing something or not being clear. take the following
setup for the "." subvol:
if i snapshot / to /__active i now have:
i now "btrfs subvolume set-default
<whatever_the_internal_id_is_for_active> /"... what happens to the
directories /usr, /etc, and /lib that _still_ exist in the "." subvol?
it's my understanding that setting the default subvol DOES NOT
actually do anything except negate the need to use the "subvol=3D<id>"
mount option... the "." subvolume still exists, still can be mounted
independently, still has files in it, and still is a parent the the
now default __active subvol and thus CANNOT be removed.
can i be confirmed on this reasoning? it seems to me that the
original subvolume is somewhat immutable in its location and relation
to other, "child" subvolumes. it's the only one that cannot be
"placed" into a different subvolume; it MUST be the ultimate parent.
am i off base here or misinterpreting what "set-default" actually does
(Arch is still on 2.6.33, i can't use set-default yet so i admit i
haven't really played with it yet)? i wouldn't think that simply
setting a new default is the same as setting a new top-level
subvolume; am i wrong?
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-05-19 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 6:50 default subvolume abilities/restrictions C Anthony Risinger
2010-05-19 14:20 ` Chris Ball
2010-05-19 14:55 ` C Anthony Risinger [this message]
2010-05-19 11:56 R: " kreijack
2010-05-19 14:01 ` C Anthony Risinger
2010-05-19 17:58 ` Goffredo Baroncelli
2010-06-12 5:24 ` C Anthony Risinger
2010-06-12 23:06 ` C Anthony Risinger
2010-06-13 0:22 ` David Brown
2010-06-13 1:06 ` C Anthony Risinger
2010-06-13 17:47 ` C Anthony Risinger
2010-06-18 21:01 ` C Anthony Risinger
2010-06-29 13:20 ` Hubert Kario
2010-06-29 15:23 ` Goffredo Baroncelli
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).