R: default subvolume abilities/restrictions

R: default subvolume abilities/restrictions

[kreijack]

Hi Anthony,

I think that for you may be interested to read this thread

http://kerneltrap.org/mailarchive/linux-btrfs/2009/11/20/6588643/thread

and to read a my blog about this argument

http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html

Regards
Goffredo


>----Messaggio originale----
>Da: anthony@extof.me
>Data: 19/05/2010 8.50
>A: <linux-btrfs@vger.kernel.org>
>Ogg: default subvolume abilities/restrictions
>
>hi,
>
>i'm working on an initrd hook
>[http://aur.archlinux.org/packages.php?ID=33376] to support
>non-volatile system rollbacks (promoting a temporary rollback snapshot
>to the new active/default).  when the system is installed to the
>default/"." subvolume (as many users probably initially do), it is
>more difficult/messier to manage system state; there are empty folders
>in each "child" snapshot where a subvolume used to exist (this seems
>like BUG to me, dir should not exist?) in the default subvolume. these
>grow/vary with time.  to work around this and for cleaner
>implementation, i'll intend to permanently boot a named subvolume
>[__active] (though its contents may be swapped out).  ultimately, i
>have to tell the user to manually remove the old junk (/usr, /etc,
>/var, etc...) from the default subvolume (since its really in the
>/__active subvolume)
>
>moving along to a question... can the default subvolume be
>swapped/removed/renamed/popped/shifted?
>
>what would have been useful, would be the ability to generate an
>empty, parent subvolume to _contain_ the current one, and rename it to
>__active.  btrfs gives rise to a "subroot" structure; the structure
>beneath the root.
>
>is something like this possible or can be added?
>
>an alternative idea i had was "promoting" a subvolume to be the new
>root, and anything "above" the new root is lost/forgotten.  then i
>could create the subroot structure in a subvol, snapshot the default
>subvol to where i want it, and promote the subvol to be the new root.
>like a permanent pivot_root/chroot.
>
>great stuff,
>
>C Anthony
>--
>To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Wed, May 19, 2010 at 6:56 AM, kreijack@libero.it <kreijack@libero.it> wrote:
> Hi Anthony,
>
> I think that for you may be interested to read this thread
>
> http://kerneltrap.org/mailarchive/linux-btrfs/2009/11/20/6588643/thread
>
> and to read a my blog about this argument
>
> http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html
>
> Regards
> Goffredo

thanks for the pointers, however the thread doesn't really offer a
solution or an indication of whether this will/can be possible :-(,
and your blog basically comes to the same conclusion that i already
agree with; the system should be installed into a subvolume from day
1.  i could be mistaken here, but in my experience, you cannot remove
a subvolume that has another subvolume within it.  thus, setting a new
default subvolume doesn't actually change the heirarchy of subvolumes,
and since the original default subvol (.) contains all other
subvolumes, it still cannot be removed, as it's the ultimate parent
subvolume (even though it's not necessarily the default anymore).  is
this correct?

i need a way, programmatically and safely, to "move" the users
installation from the original subvolume into an isolated subvolume
called __active (what you called "rootfs" in you thread/blog), or to
generate a new, empty default/root subvolume and place the current
default subvol (.) _into_ it...  how can this be done?  until i figure
this out i have to tell the user to manually remove the stagnant files
from the dot (.) subvolume (usr/etc/lib...), since i don't think my
users would appreciate me issuing an "rm -rf" against their system.

any other ideas/input?

C Anthony

ps. a recursive snapshotting tool could be useful too (if / and /home
were both subvols, the tool would create both when / was snapped,
instead of /home being an empty folder in the snapshot).

Re: default subvolume abilities/restrictions

[Goffredo Baroncelli]

On Wednesday, May 19, 2010, C Anthony Risinger wrote:
> On Wed, May 19, 2010 at 6:56 AM, kreijack@libero.it <kreijack@libero.it> 
wrote:
> > Hi Anthony,
> >
> > I think that for you may be interested to read this thread
> >
> > http://kerneltrap.org/mailarchive/linux-btrfs/2009/11/20/6588643/thread
> >
> > and to read a my blog about this argument
> >
> > http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html
> >
> > Regards
> > Goffredo
> 
> thanks for the pointers, however the thread doesn't really offer a
> solution or an indication of whether this will/can be possible :-(,
> and your blog basically comes to the same conclusion that i already
> agree with; the system should be installed into a subvolume from day
> 1.  i could be mistaken here, but in my experience, you cannot remove
> a subvolume that has another subvolume within it.  thus, setting a new
> default subvolume doesn't actually change the heirarchy of subvolumes,
> and since the original default subvol (.) contains all other
> subvolumes, it still cannot be removed, as it's the ultimate parent
> subvolume (even though it's not necessarily the default anymore).  is
> this correct?

On the basis of my experiences I agree with you. I think that it was not a 
good design to link the subvolumes to directory entries. I prefer that the 
subvolumes live in a different namespace, and it were mounted when required.

> i need a way, programmatically and safely, to "move" the users
> installation from the original subvolume into an isolated subvolume
> called __active (what you called "rootfs" in you thread/blog), or to
> generate a new, empty default/root subvolume and place the current
> default subvol (.) _into_ it...  how can this be done?  until i figure
> this out i have to tell the user to manually remove the stagnant files
> from the dot (.) subvolume (usr/etc/lib...), since i don't think my
> users would appreciate me issuing an "rm -rf" against their system.
> 
> any other ideas/input?

I am not sure to have understood well. But a possible solution may be to 
- snapshot the default subvolume to a rootfs.
- boot in the rootfs subvolume
- mount the default subvol (mount -o subvol=default /dev/sdX /mnt/default)
- remove (carefully) the file under the default subvolume except the  
subvolume(s) (something like rm --one-file-system /mnt/default/).


> 
> C Anthony
> 
> ps. a recursive snapshotting tool could be useful too (if / and /home
> were both subvols, the tool would create both when / was snapped,
> instead of /home being an empty folder in the snapshot).




> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger <anthony@extof.me> =
wrote:
> ..........
> i need a way, programmatically and safely, to "move" the users
> installation from the original subvolume into an isolated subvolume
> ..........
> or to generate a new, empty default/root subvolume and place the curr=
ent
> default subvol (.) _into_ it... =A0how can this be done?

can any devs out there make this happen?  note, what i'm looking for
is _not_ setting the default subvolume to be mounted, but actually
moving/renaming the default (.) subvolume itself.  essentially, can we
get a command to do this:

# btrfs subvolume create new_root
# mv . new_root/old_root

that unsurprisingly fails with:

mv: cannot move `.' to `new_root/old_root': Device or resource busy

could we extend btrfs-progs tools to allow something like this?  does
the on disk format support _moving_ the default subvol?  this
operation is critical to "upgrade" a user who has installed their
system into the default subvol, as most naturally would.  clean
rollback systems/structures depend on the user having his system
installed to an isolated subvol, NOT the default.

what sayith you?

thanks,
C Anthony

additionally, is anything like the following on a TODO list anywhere?
thanks again.

> ps. a recursive snapshotting tool could be useful too (if / and /home
> were both subvols, the tool would create both when / was snapped,
> instead of /home being an empty folder in the snapshot [BUG?]).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Sat, Jun 12, 2010 at 12:24 AM, C Anthony Risinger <anthony@extof.me>=
 wrote:
> On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger <anthony@extof.me=
> wrote:
>> ..........
>> i need a way, programmatically and safely, to "move" the users
>> installation from the original subvolume into an isolated subvolume
>> ..........
>> or to generate a new, empty default/root subvolume and place the cur=
rent
>> default subvol (.) _into_ it... =A0how can this be done?
>
> can any devs out there make this happen? =A0note, what i'm looking fo=
r
> is _not_ setting the default subvolume to be mounted, but actually
> moving/renaming the default (.) subvolume itself. =A0essentially, can=
 we
> get a command to do this:
>
> # btrfs subvolume create new_root
> # mv . new_root/old_root
>
> that unsurprisingly fails with:
>
> mv: cannot move `.' to `new_root/old_root': Device or resource busy
>
> could we extend btrfs-progs tools to allow something like this? =A0do=
es
> the on disk format support _moving_ the default subvol? =A0this
> operation is critical to "upgrade" a user who has installed their
> system into the default subvol, as most naturally would. =A0clean
> rollback systems/structures depend on the user having his system
> installed to an isolated subvol, NOT the default.
>
> what sayith you?

i might even try to implement this myself...

can i at least get confirmation that the above is possible?

all i want to do is create a new/empty subvol, put the old top-level
subvol inside it, and make the empty subvol the new root.  this lets
me put a users installation INTO a subvol even though they originally
installed the system into the root subvol.

guidance please?  chris? :-)

thanks,
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[David Brown]

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

   # btrfs subvolume snapshot . new_root
   # mkdir old_root
   # mv * old_root
   # 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

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@davidb.org> wrote:
> 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 better
solution...

but alas, a snapshot isn't necessary.  i can create an empty subvol
"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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@extof.me> =
wrote:
> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@davidb.org> wrote=
:
>> 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 bette=
r
> solution...
>
> but alas, a snapshot isn't necessary. =A0i can create an empty subvol
> "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.  i don't know how long because i went to
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.  this space will in time become dead wasted space unless my
users manually "rm -rf" themselves.

so... any input on this?  how can i effectively, and efficiently, move
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 subvol
INTO it with a new name.

thoughts?

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger <anthony@extof.me>=
 wrote:
> On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@extof.me=
> wrote:
>> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@davidb.org> wrot=
e:
>>> 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 (.)=
=2E
>> thus a way to "parent" the default subvol (old_root/.) seemed a bett=
er
>> solution...
>>
>> but alas, a snapshot isn't necessary. =A0i can create an empty subvo=
l
>> "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 =
to
> 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=
ove
> 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=
l
> 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
everything....

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.

thanks,
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[Hubert Kario]

On Friday 18 June 2010 23:01:37 C Anthony Risinger wrote:
> On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger <anthony@extof.m=
e>=20
wrote:
> > On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@extof.=
me>=20
wrote:
> >> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@davidb.org> wr=
ote:
> >>> On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrot=
e:
> >>>>> # btrfs subvolume create new_root
> >>>>> # mv . new_root/old_root
> >>>>=20
> >>>> can i at least get confirmation that the above is possible?
> >>>=20
> >>> I've had no problem with
> >>>=20
> >>>  # btrfs subvolume snapshot . new_root
> >>>  # mkdir old_root
> >>>  # mv * old_root
> >>>  # rm -rf old_root
> >>>=20
> >>> Make sure the 'mv' fails fo move new_root, and I'd look at the
> >>> new_root before removing everything.
> >>>=20
> >>> David
> >>=20
> >> heh, yeah i as i was writing the last email i realized that all i
> >> really wanted was to:
> >>=20
> >> # mv * new_root
> >>=20
> >> 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 (=
=2E).
> >> thus a way to "parent" the default subvol (old_root/.) seemed a be=
tter
> >> solution...
> >>=20
> >> but alas, a snapshot isn't necessary.  i can create an empty subvo=
l
> >> "new_root", and then "mv * new_root".
> >>=20
> >> 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.
> >>=20
> >> C Anthony
> >=20
> > ok i take it all back, i DO need this...
> >=20
> > i rewrote my initramfs hook to do the following operations:
> >=20
> > # btrfs subvolume create /new_root
> > # mv /* /new_root
> >=20
> > instead of what i had:
> >=20
> > # btrfs subvolume snapshot / /new_root
> >=20
> > 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.  i don't know how long because i went =
to
> > bed.
> >=20
> > this is why i need a way to "parent" the default subvolume.
> >=20
> > 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.  this space will in time become dead wasted space unless my
> > users manually "rm -rf" themselves.
> >=20
> > so... any input on this?  how can i effectively, and efficiently, m=
ove
> > a users installation into a dedicated subvolume, when they have
> > already installed into the default subvolume?
> >=20
> > 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 sub=
vol
> > INTO it with a new name.
> >=20
> > thoughts?
>=20
> 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
> everything....
>=20
> i need the ability to "move" the default subvolume into a new, empty
> subvolume.  the empty subvolume then becomes the new default.
>=20
> 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.
>=20
> 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.
>=20
> moving the users install via "mv" into an empty subvol does not work.
> everything is actually copied =3D slow,slow,slow.

I don't have a btrfs file system on hand to actually try it, but did yo=
u try=20
copying using "cp --reflink=3Dalways"?

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

>=20
> thanks,
> C Anthony

--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: default subvolume abilities/restrictions

[Goffredo Baroncelli]

On Tuesday, June 29, 2010, Hubert Kario wrote:
> On Friday 18 June 2010 23:01:37 C Anthony Risinger wrote:
> > On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger <anthony@extof=
=2Eme>=20
> wrote:
> > > On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@exto=
f.me>=20
> wrote:
> > >> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@davidb.org> =
wrote:
> > >>> On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wr=
ote:
> > >>>>> # btrfs subvolume create new_root
> > >>>>> # mv . new_root/old_root
> > >>>>=20
> > >>>> can i at least get confirmation that the above is possible?
> > >>>=20
> > >>> I've had no problem with
> > >>>=20
> > >>>  # btrfs subvolume snapshot . new_root
> > >>>  # mkdir old_root
> > >>>  # mv * old_root
> > >>>  # rm -rf old_root
> > >>>=20
> > >>> Make sure the 'mv' fails fo move new_root, and I'd look at the
> > >>> new_root before removing everything.
> > >>>=20
> > >>> David
> > >>=20
> > >> heh, yeah i as i was writing the last email i realized that all =
i
> > >> really wanted was to:
> > >>=20
> > >> # mv * new_root
> > >>=20
> > >> for some reason i was convinced that i must snapshot the old_roo=
t (.)
> > >> to new_root... and then remove the erroneous stuff from old_root=
 (.).
> > >> thus a way to "parent" the default subvol (old_root/.) seemed a =
better
> > >> solution...
> > >>=20
> > >> but alas, a snapshot isn't necessary.  i can create an empty sub=
vol
> > >> "new_root", and then "mv * new_root".
> > >>=20
> > >> 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.
> > >>=20
> > >> C Anthony
> > >=20
> > > ok i take it all back, i DO need this...
> > >=20
> > > i rewrote my initramfs hook to do the following operations:
> > >=20
> > > # btrfs subvolume create /new_root
> > > # mv /* /new_root
> > >=20
> > > instead of what i had:
> > >=20
> > > # btrfs subvolume snapshot / /new_root
> > >=20
> > > and it resulted in scarily COPYING my entire system... several gi=
gs
> > > worth... to the newly created subvolume, which took forever, and
> > > grinded on my HD for awhile.  i don't know how long because i wen=
t to
> > > bed.
> > >=20
> > > this is why i need a way to "parent" the default subvolume.
> > >=20
> > > 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.  this space will in time become dead wasted space unless my
> > > users manually "rm -rf" themselves.
> > >=20
> > > so... any input on this?  how can i effectively, and efficiently,=
 move
> > > a users installation into a dedicated subvolume, when they have
> > > already installed into the default subvolume?
> > >=20
> > > i think the best way is what i originally suggested; make an empt=
y
> > > subvolume the new top-level subvol, and place the old top-level s=
ubvol
> > > INTO it with a new name.
> > >=20
> > > thoughts?
> >=20
> > 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
> > everything....
> >=20
> > i need the ability to "move" the default subvolume into a new, empt=
y
> > subvolume.  the empty subvolume then becomes the new default.
> >=20
> > the end result is moving the users installation into a dedicated
> > subvolume, cleanly and efficiently, so the system can do other thin=
gs
> > with the "subroot" structure.
> >=20
> > the way i am doing it now is snapshotting the users / to /__active.=
=2E.
> > however, the side effect is an entire system worth of files that wi=
ll
> > in time become dead space.
> >=20
> > moving the users install via "mv" into an empty subvol does not wor=
k.
> > everything is actually copied =3D slow,slow,slow.
>=20
> I don't have a btrfs file system on hand to actually try it, but did =
you try=20
> copying using "cp --reflink=3Dalways"?

This should work for the files but not for the directories.

The real problem is that the "." (default) subvolume is a special case=20
subvolume. It is difficult to drop because all subvolumes depend by its=
=2E

The 'mv' command permits to move the subvolumes between subvolumes, but=
 if you=20
want to be capable to move all subvolumes, the "." (default) subvolumes=
 has to=20
be mounted.

It was created the "set-default" command to change the "default" subvol=
ume.=20
But it didn't solve all the problem.

I am not an expert of the internal of btrfs, but I am still convinced t=
hat the=20
subvolumes have to live in a different name-space, and them have to be =
mounted=20
_only_ by  "mount -o subvol=3D<name>...".

IMHO for now the best thing to do, is always create the root filesystem=
 in a=20
non-default subvolume, and use the "." (default) subvolume _only_ to ma=
nage=20
the subvolumes.

To move the default subvolume, the best thing to do it is to clone and =
then=20
remove the original file.

>=20
> >=20
> > ideas???  how can i "parent" the default subvol with an empty subvo=
l?
> > this seems a legitimate operation.
>=20
> >=20
> > thanks,
> > C Anthony
>=20



> --=20
> Hubert Kario
> QBS - Quality Business Software
> 02-656 Warszawa, ul. Ksawer=F3w 30/85
> tel. +48 (22) 646-61-51, 646-74-24
> www.qbs.com.pl
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>=20


--=20
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinw=
ind.it>
Key fingerprint =3D 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

default subvolume abilities/restrictions

[C Anthony Risinger]

hi,

i'm working on an initrd hook
[http://aur.archlinux.org/packages.php?ID=33376] to support
non-volatile system rollbacks (promoting a temporary rollback snapshot
to the new active/default).  when the system is installed to the
default/"." subvolume (as many users probably initially do), it is
more difficult/messier to manage system state; there are empty folders
in each "child" snapshot where a subvolume used to exist (this seems
like BUG to me, dir should not exist?) in the default subvolume. these
grow/vary with time.  to work around this and for cleaner
implementation, i'll intend to permanently boot a named subvolume
[__active] (though its contents may be swapped out).  ultimately, i
have to tell the user to manually remove the old junk (/usr, /etc,
/var, etc...) from the default subvolume (since its really in the
/__active subvolume)

moving along to a question... can the default subvolume be
swapped/removed/renamed/popped/shifted?

what would have been useful, would be the ability to generate an
empty, parent subvolume to _contain_ the current one, and rename it to
__active.  btrfs gives rise to a "subroot" structure; the structure
beneath the root.

is something like this possible or can be added?

an alternative idea i had was "promoting" a subvolume to be the new
root, and anything "above" the new root is lost/forgotten.  then i
could create the subroot structure in a subvol, snapshot the default
subvol to where i want it, and promote the subvol to be the new root.
like a permanent pivot_root/chroot.

great stuff,

C Anthony

Re: default subvolume abilities/restrictions

[Chris Ball]

Hi,

   > moving along to a question... can the default subvolume be
   > swapped/removed/renamed/popped/shifted?

I think "btrfs subvolume list; btrfs subvolume set-default <id> <path>"
does what you need.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>
One Laptop Per Child

Re: default subvolume abilities/restrictions

[C Anthony Risinger]

On Wed, May 19, 2010 at 9:20 AM, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> =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:

/
/etc
/usr
/lib

if i snapshot / to /__active i now have:

/
/etc
/usr
/lib
/__active

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?

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html