R: default subvolume abilities/restrictions

----Messaggio originale----
Da: [email protected]
Data: 19/05/2010 8.50
A: <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

On Wed, May 19, 2010 at 6:56 AM, [email protected] <[email protected]>

Quoted 4 lines

Hi Anthony,

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

Quoted 8 lines

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

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

..........
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=

default subvol (.) _into_ it... =A0how can this be done?

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?]).

Quoted 5 lines · On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger <[email protected]= 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=

Quoted 1 line

default subvol (.) _into_ it... =A0how can this be done?

can any devs out there make this happen? =A0note, what i'm looking fo=

is _not_ setting the default subvolume to be mounted, but actually moving/renaming the default (.) subvolume itself. =A0essentially, can=

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=

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?

Quoted 2 lines

# btrfs subvolume create new_root
# mv . new_root/old_root

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

Quoted 4 lines · C Anthony Risinger

Quoted 2 lines

# 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

On Sat, Jun 12, 2010 at 7:22 PM, David Brown <[email protected]> wrote=

Quoted 14 lines · C Anthony Risinger

Quoted 5 lines

Quoted 3 lines

# 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

Quoted 4 lines

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=

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

Quoted 1 line · On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <[email protected]= wrote:

On Sat, Jun 12, 2010 at 7:22 PM, David Brown <[email protected]> wrot=

Quoted 17 lines

Quoted 17 lines · C Anthony Risinger

Quoted 5 lines

Quoted 3 lines

# 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.

Quoted 8 lines

Quoted 1 line

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 (.=

Quoted 1 line

to new_root... and then remove the erroneous stuff from old_root (.)=

Quoted 1 line

thus a way to "parent" the default subvol (old_root/.) seemed a bett=

Quoted 3 lines

solution...

but alas, a snapshot isn't necessary. =A0i can create an empty subvo=

Quoted 7 lines

"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?

On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger <[email protected]=

Quoted 1 line

On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@extof.=

Quoted 1 line

Quoted 1 line

On Sat, Jun 12, 2010 at 7:22 PM, David Brown <[email protected]> wr=

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrot=

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

Quoted 4 lines

Quoted 2 lines

# 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

Quoted 7 lines

Quoted 7 lines

=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 =

Quoted 1 line

Quoted 1 line

to new_root... and then remove the erroneous stuff from old_root (=

Quoted 1 line

Quoted 1 line

thus a way to "parent" the default subvol (old_root/.) seemed a be=

Quoted 3 lines

Quoted 3 lines

solution...
=20
but alas, a snapshot isn't necessary. i can create an empty subvo=

Quoted 7 lines

Quoted 7 lines

"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

Quoted 5 lines

=20
ok i take it all back, i DO need this...
=20
i rewrote my initramfs hook to do the following operations:
=20

Quoted 10 lines

# 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 =

Quoted 10 lines

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=

Quoted 5 lines

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=

Quoted 3 lines

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.

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

=20
thanks,
C Anthony

Quoted 1 line · 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=

Quoted 1 line · wrote:

Quoted 1 line

On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@exto=

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

On Sat, Jun 12, 2010 at 7:22 PM, David Brown <[email protected]> =

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wr=

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

Quoted 4 lines

Quoted 2 lines

# 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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

=20
heh, yeah i as i was writing the last email i realized that all =

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

really wanted was to:
=20

# mv * new_root
=20
for some reason i was convinced that i must snapshot the old_roo=

Quoted 1 line

Quoted 1 line

Quoted 1 line

to new_root... and then remove the erroneous stuff from old_root=

Quoted 1 line

Quoted 1 line

Quoted 1 line

thus a way to "parent" the default subvol (old_root/.) seemed a =

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

solution...
=20
but alas, a snapshot isn't necessary. i can create an empty sub=

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

"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

Quoted 5 lines

Quoted 5 lines

=20
ok i take it all back, i DO need this...
=20
i rewrote my initramfs hook to do the following operations:
=20

Quoted 8 lines

Quoted 8 lines

# 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=

Quoted 2 lines

Quoted 2 lines

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=

Quoted 6 lines

Quoted 6 lines

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 =

Quoted 4 lines

Quoted 4 lines

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,=

Quoted 4 lines

Quoted 4 lines

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=

Quoted 1 line

Quoted 1 line

subvolume the new top-level subvol, and place the old top-level s=

Quoted 9 lines

Quoted 3 lines

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=

Quoted 4 lines

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=

Quoted 3 lines

with the "subroot" structure.
=20
the way i am doing it now is snapshotting the users / to /__active.=

Quoted 1 line

however, the side effect is an entire system worth of files that wi=

Quoted 3 lines

in time become dead space.
=20
moving the users install via "mv" into an empty subvol does not wor=

Quoted 1 line

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 =

copying using "cp --reflink=3Dalways"?

=20

Quoted 2 lines

=20
ideas??? how can i "parent" the default subvol with an empty subvo=

Quoted 1 line

this seems a legitimate operation.

=20

Quoted 3 lines

=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=

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
=20