archive mirror
 help / color / mirror / Atom feed
From: C Anthony Risinger <>
Subject: Re: default subvolume abilities/restrictions
Date: Fri, 18 Jun 2010 16:01:37 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger <>=
> On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <
> wrote:
>> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <> wrot=
>>> On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote:
>>>>> # btrfs subvolume create new_root
>>>>> # mv . new_root/old_root
>>>> can i at least get confirmation that the above is possible?
>>> I've had no problem with
>>> =A0# btrfs subvolume snapshot . new_root
>>> =A0# mkdir old_root
>>> =A0# mv * old_root
>>> =A0# rm -rf old_root
>>> Make sure the 'mv' fails fo move new_root, and I'd look at the
>>> new_root before removing everything.
>>> David
>> heh, yeah i as i was writing the last email i realized that all i
>> really wanted was to:
>> # mv * new_root
>> for some reason i was convinced that i must snapshot the old_root (.=
>> to new_root... and then remove the erroneous stuff from old_root (.)=
>> thus a way to "parent" the default subvol (old_root/.) seemed a bett=
>> solution...
>> but alas, a snapshot isn't necessary. =A0i can create an empty subvo=
>> "new_root", and then "mv * new_root".
>> i don't know how that escaped me :-), sorry for all the noise.
>> however, there probably is a legitimate use case for wanting to
>> replace the default subvolume, but this isn't it.
>> C Anthony
> ok i take it all back, i DO need this...
> i rewrote my initramfs hook to do the following operations:
> # btrfs subvolume create /new_root
> # mv /* /new_root
> instead of what i had:
> # btrfs subvolume snapshot / /new_root
> and it resulted in scarily COPYING my entire system... several gigs
> worth... to the newly created subvolume, which took forever, and
> grinded on my HD for awhile. =A0i don't know how long because i went =
> bed.
> this is why i need a way to "parent" the default subvolume.
> a snapshot is nice and quick, but it leaves / full of erroneous
> folders (dev/etc/usr/lib), an entire system, that will no longer be
> used. =A0this space will in time become dead wasted space unless my
> users manually "rm -rf" themselves.
> so... any input on this? =A0how can i effectively, and efficiently, m=
> a users installation into a dedicated subvolume, when they have
> already installed into the default subvolume?
> i think the best way is what i originally suggested; make an empty
> subvolume the new top-level subvol, and place the old top-level subvo=
> INTO it with a new name.
> thoughts?

can i get a little feedback on this problem?  i choke slightly when
telling users the only way to clean their old / is by rm -rf'ing

i need the ability to "move" the default subvolume into a new, empty
subvolume.  the empty subvolume then becomes the new default.

the end result is moving the users installation into a dedicated
subvolume, cleanly and efficiently, so the system can do other things
with the "subroot" structure.

the way i am doing it now is snapshotting the users / to /__active...
however, the side effect is an entire system worth of files that will
in time become dead space.

moving the users install via "mv" into an empty subvol does not work.
everything is actually copied =3D slow,slow,slow.

ideas???  how can i "parent" the default subvol with an empty subvol?
this seems a legitimate operation.

C Anthony
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
the body of a message to
More majordomo info at

  reply	other threads:[~2010-06-18 21:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 11:56 R: default subvolume abilities/restrictions 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 [this message]
2010-06-29 13:20               ` Hubert Kario
2010-06-29 15:23                 ` Goffredo Baroncelli
  -- strict thread matches above, loose matches on Subject: below --
2010-05-19  6:50 C Anthony Risinger
2010-05-19 14:20 ` Chris Ball
2010-05-19 14:55   ` C Anthony Risinger

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:

* 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).