Ananconda

Gene Czarcinski gene at czarc.net
Mon Sep 23 18:38:10 UTC 2013


On 09/23/2013 01:39 PM, Chris Murphy wrote:
> On Sep 23, 2013, at 9:44 AM, Gene Czarcinski <gene at czarc.net> wrote:
>> How about the reuse of btrfs subvolumes?
> It is possible to reuse btrfs subvolumes for mount points other than root. Root requires a new subvolume.
>
>> It seems to me that the only way to do that is to delete the subvolume and then reallocate it which is precisely what I do in my KVM kickstart installs.  I first bootup in rescue mode and delete the old root subvolume and then reboot to do the install.  I probably need to figure out out a pre-install script which will do that.
> No need to delete the previous subvolume unless you want to delete the installation contained on it.
>
>> Is this worth an RFE?  I am thinking of an RFE for kickstart.   I assume (I have not tried it) that I can reuse an subvolume by first deleting and "reclaiming" the space from a regular install.
> Reuse is inconsistent with delete, but yes you can't reuse an existing subvolume for rootfs for a new install.
>
>
> Chris Murphy
>
As a matter of fact, my use of BTRFS in "production" does use this. I 
have a pair of SSD's that I use for BTRFS with root and home on them.  
Data is striped and metadata is mirrored.  subvol root18 is ... Fedora 
18 and subvol root19 is ... Fedora 19.  One of the nice things about 
using BTRFS is that  the free space is shared by all. When I get around 
to installing Fedora 20, I will delete subvol root18 and then install 
Fedora 20 on subvol root20.

Over the many years I have been dealing with operating systems (and I 
have been doing it well before linux came along) is to NOT destroy a 
working system when you install a new version of a system. Therefor, 
each one of my hardware boxes is multi-boot with space allocated for at 
least three versions of systems: current, old/new, and test.  Oh yes, 
and the software and (user data) are also kept separate.  This was 
learned (as good things usually are) "the hard way".

Gene


More information about the devel mailing list