[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: default subvolume abilities/restrictions
From:       Goffredo Baroncelli <kreijack () gmail ! com>
Date:       2010-06-29 15:23:23
Message-ID: 201006291723.23939.kreijack () libero ! it
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]