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@xxxxxxxx> wrote: > > On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger <anthony@xxxxxxxx> wrote: > >> On Sat, Jun 12, 2010 at 7:22 PM, David Brown <btrfs@xxxxxxxxxx> 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 > >>> > >>> # 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 > >> > >> 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 > > > > 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? > > 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 = slow,slow,slow. I don't have a btrfs file system on hand to actually try it, but did you try copying using "cp --reflink=always"? > > ideas??? how can i "parent" the default subvol with an empty subvol? > this seems a legitimate operation. > > thanks, > C Anthony -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
