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 >-- 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
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 > Goffredothanks 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- 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
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 current > default subvol (.) _into_ it... how 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
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 current >> default subvol (.) _into_ it... how 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?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
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 -- 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
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 > > # 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. > > Davidheh, 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
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 >> >> # 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 Anthonyok 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
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> 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. 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
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.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> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.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> 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"?This should work for the files but not for the directories. The real problem is that the "." (default) subvolume is a special case subvolume. It is difficult to drop because all subvolumes depend by its. The ''mv'' command permits to move the subvolumes between subvolumes, but if you want to be capable to move all subvolumes, the "." (default) subvolumes has to be mounted. It was created the "set-default" command to change the "default" subvolume. But it didn''t solve all the problem. I am not an expert of the internal of btrfs, but I am still convinced that the subvolumes have to live in a different name-space, and them have to be mounted _only_ by "mount -o subvol=<name>...". IMHO for now the best thing to do, is always create the root filesystem in a non-default subvolume, and use the "." (default) subvolume _only_ to manage the subvolumes. To move the default subvolume, the best thing to do it is to clone and then remove the original file.> > > > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it> Key fingerprint = 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
Maybe Matching Threads
- [PATCH] Allow cross subvolume reflinks (2nd attempt)
- [PATCH V2] Btrfs: fix subvolume mount by name problem when default mount subvolume is set
- [PATCH] BTRFS-PROG: recursively subvolume snapshot and delete
- snapshot issues
- Create subvolume from a directory?