moving a subvol

moving a subvol

[Gene Czarcinski]

I have hunted high and low for the information but, if it is out there, 
it is well hidden.

What I want to do:  I want to relocate (move) a subvolume from one BTRFS 
volume to a different BTRFS volume.

I have seen the writeup for incremental backup which takes a snapshot, 
and then using btrfs-send and btrfs-receive to create a copy on a 
different volume.  That works fine except the btrfs-receive set the new 
copy to be readonly.

What I want to do is to use that new subvolume read/write.  The only way 
I have figured out to do this is to create another snapshot on the new 
volume which is NOT readonly.  I believe that means I need to keep both 
of these subvolumes around.

Gene

Re: moving a subvol

[Gene Czarcinski]

On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
> I have hunted high and low for the information but, if it is out there,
> it is well hidden.
>
> What I want to do:  I want to relocate (move) a subvolume from one BTRFS
> volume to a different BTRFS volume.
>
> I have seen the writeup for incremental backup which takes a snapshot,
> and then using btrfs-send and btrfs-receive to create a copy on a
> different volume.  That works fine except the btrfs-receive set the new
> copy to be readonly.
>
> What I want to do is to use that new subvolume read/write.  The only way
> I have figured out to do this is to create another snapshot on the new
> volume which is NOT readonly.  I believe that means I need to keep both
> of these subvolumes around.

As soon as I sent this I believe I found the answer.

I was sort of right about creating the new read-write (NOT readonly) 
snapshot.  After it is created simply delete the one which was created 
by btrfs-receive.

I also found out that if you want to rename a subvolume, siple do it 
with "mv" like you would for a directory or a file.

OK folks, do I have it correct?

Gene

Re: moving a subvol

[Chris Murphy]

On Dec 13, 2013, at 9:31 AM, Gene Czarcinski <gczarcinski@gmail.com> wrote:

> On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
>> I have hunted high and low for the information but, if it is out there,
>> it is well hidden.
>> 
>> What I want to do:  I want to relocate (move) a subvolume from one BTRFS
>> volume to a different BTRFS volume.
>> 
>> I have seen the writeup for incremental backup which takes a snapshot,
>> and then using btrfs-send and btrfs-receive to create a copy on a
>> different volume.  That works fine except the btrfs-receive set the new
>> copy to be readonly.
>> 
>> What I want to do is to use that new subvolume read/write.  The only way
>> I have figured out to do this is to create another snapshot on the new
>> volume which is NOT readonly.  I believe that means I need to keep both
>> of these subvolumes around.
> 
> As soon as I sent this I believe I found the answer.
> 
> I was sort of right about creating the new read-write (NOT readonly) snapshot.  After it is created simply delete the one which was created by btrfs-receive.
> 
> I also found out that if you want to rename a subvolume, siple do it with "mv" like you would for a directory or a file.
> 
> OK folks, do I have it correct?

Yes.


Chris Murphy

Re: moving a subvol

[Chris Murphy]

On Dec 13, 2013, at 10:37 AM, Cobin Bluth <cbluth@gmail.com> wrote:
> That seems a little less intuitive than one would think. I wonder if there would an argument to specify read-write for btrfs-receive.

I'm going to guess it's on purpose to prevent writes from happening in the subvolume while it's still being received. The send file is a stream so my interpretation of what's going on is that subvolume's file system isn't really in a state to be modified until it's completely done being written. And for that matter, it's the same thing with sending. The wiki says send requires subvolumes to be ro, and all of the examples there are ro subvolumes.

I don't know that this is an apt analogy, but think of dd'ing a partition that contains a live mounted volume. Oops - not a good idea right? Because as you dd the first part, the uncopied portion is being modified and is now inconsistent. 

Chris Murphy

Re: moving a subvol

[Gene Czarcinski]

On 12/13/2013 01:02 PM, Chris Murphy wrote:
>
> On Dec 13, 2013, at 10:37 AM, Cobin Bluth <cbluth@gmail.com> wrote:
>> That seems a little less intuitive than one would think. I wonder if there would an argument to specify read-write for btrfs-receive.
>
> I'm going to guess it's on purpose to prevent writes from happening in the subvolume while it's still being received. The send file is a stream so my interpretation of what's going on is that subvolume's file system isn't really in a state to be modified until it's completely done being written. And for that matter, it's the same thing with sending. The wiki says send requires subvolumes to be ro, and all of the examples there are ro subvolumes.
>
> I don't know that this is an apt analogy, but think of dd'ing a partition that contains a live mounted volume. Oops - not a good idea right? Because as you dd the first part, the uncopied portion is being modified and is now inconsistent.
>
>
Seems to have worked fine.  What more could I ask for.

With Fedora 20 a go for gold, I decided to update to Fedora 20 on almost 
all of my systems.  At the same time I decided to do some consolidation 
and restructuring of my disk layouts to put almost all of it under some 
BTRFS volumes.

I really did not want to install Fedora 19 again and just want to move 
the F19 rootfs from one volume to a newer other volume.  It required 
some editing of /etc/fstab to use the  new UUIDs and also some manual 
editing (ugh) of grub.cfg so that it had the correct UUIDs for the 
volume with subvol=root4.

Next it is to delete the old BTRFS volume, use fdisk to increase the 
size of the partition and then attempt to increate the size of this new 
volume.  I hope I don't get bit in the rear end with this.

Gene

Re: moving a subvol

[Chris Samuel]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Fri, 13 Dec 2013 02:25:34 PM Gene Czarcinski wrote:

> Next it is to delete the old BTRFS volume, use fdisk to increase the 
> size of the partition and then attempt to increate the size of this new 
> volume.  I hope I don't get bit in the rear end with this.

Just make sure you have good (tested) backups..

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: moving a subvol

[Gene Czarcinski]

On 12/14/2013 02:07 AM, Chris Samuel wrote:
> On Fri, 13 Dec 2013 02:25:34 PM Gene Czarcinski wrote:
>
>> Next it is to delete the old BTRFS volume, use fdisk to increase the
>> size of the partition and then attempt to increate the size of this new
>> volume.  I hope I don't get bit in the rear end with this.
>
> Just make sure you have good (tested) backups..
>
Data subvolumes such as for /home have separate backups but the rootfs 
subvolumes do not.  If somethings gets screwed up, it is a matter of 
reinstalling.  Since I run Fedora with anaconda I use kickstart installs 
and can easily repeat an install since it included almost everything I 
want installed.  And then I have a post-install script I run to pickup 
additional stuff.

After successfully resizing, I then repeated with a two-device BTRFS 
volume.  Here the resize needs to be done for each device.

Question:  What is did involved two BTRFS volumes on /dev/sdb1 and 
/dev/sdb2.  I deleted /dev/sdb2 and then expanded/resized /dev/sdb1. 
This worked but I assume that doing the opposite would not work.  That 
is, deleteing the "lower" /dev/sdb1 and then expanding the "upper" 
/dev/sdb2 because after rebooting the filesystem would not be at the 
beginning of the partition.

Gene

Re: moving a subvol

[Chris Murphy]

On Dec 14, 2013, at 2:57 AM, Gene Czarcinski <gczarcinski@gmail.com> wrote:
>  Since I run Fedora with anaconda I use kickstart installs and can easily repeat an install since it included almost everything I want installed.  And then I have a post-install script I run to pickup additional stuff.

This is a bit of a hijack question, but does kickstart offer a way to mount Btrfs with compression option?


Chris Murphy

Re: moving a subvol

[Gene Czarcinski]

On 12/14/2013 01:43 PM, Chris Murphy wrote:
> On Dec 14, 2013, at 2:57 AM, Gene Czarcinski <gczarcinski@gmail.com> wrote:
>>   Since I run Fedora with anaconda I use kickstart installs and can easily repeat an install since it included almost everything I want installed.  And then I have a post-install script I run to pickup additional stuff.
> This is a bit of a hijack question, but does kickstart offer a way to mount Btrfs with compression option?
>
>
> Chris Murphy
Interesting; it does not "currently" but that sounds like it should be 
(RFE time) an added option so that it would be in fstab from the start.  
It may not be that simple since if you specify compression for a 
subvolume, that means that everything anaconda installs on the subvolume 
should be subjected to compression and not just stuff written post-install.

I do not currently use compression but I should give it a try.

Chris, since I know kickstart and you do not, I will BZ the RFE. BTW, is 
this an option on the regular GUI install?

Gene

Re: moving a subvol

[Chris Murphy]

On Dec 15, 2013, at 10:40 AM, Gene Czarcinski <gczarcinski@gmail.com> wrote:

> On 12/14/2013 01:43 PM, Chris Murphy wrote:
>> On Dec 14, 2013, at 2:57 AM, Gene Czarcinski <gczarcinski@gmail.com> wrote:
>>>  Since I run Fedora with anaconda I use kickstart installs and can easily repeat an install since it included almost everything I want installed.  And then I have a post-install script I run to pickup additional stuff.
>> This is a bit of a hijack question, but does kickstart offer a way to mount Btrfs with compression option?
>> 
>> 
>> Chris Murphy
> Interesting; it does not "currently" but that sounds like it should be (RFE time) an added option so that it would be in fstab from the start.  It may not be that simple since if you specify compression for a subvolume, that means that everything anaconda installs on the subvolume should be subjected to compression and not just stuff written post-install.

It needs to be mounted with the option prior to installation, and also needs to be added to the fstab.
> 
> I do not currently use compression but I should give it a try.
> 
> Chris, since I know kickstart and you do not, I will BZ the RFE. BTW, is this an option on the regular GUI install?

No, and I'm not finding it in any of the code for kickstart or anaconda GUI. My recollection is that if it was brought into the GUI it wasn't going to offer any choice of compression algorithm, it would use the Btrfs default. Currently that's zlib, which I think maybe isn't the best default choice because while it offers higher compression ratio over lzo, it's slower to compress and decompress. HDD space is cheap, the benefit of compression isn't so much saving space as it is to make r/w faster. In all of my tests LZO does this better. I *think* Snappy is better still than LZO, but that's not yet an option.

Chris Murphy

Re: moving a subvol

[David Sterba]

On Fri, Dec 13, 2013 at 11:31:47AM -0500, Gene Czarcinski wrote:
> On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
> >I have hunted high and low for the information but, if it is out there,
> >it is well hidden.
> >
> >What I want to do:  I want to relocate (move) a subvolume from one BTRFS
> >volume to a different BTRFS volume.
> >
> >I have seen the writeup for incremental backup which takes a snapshot,
> >and then using btrfs-send and btrfs-receive to create a copy on a
> >different volume.  That works fine except the btrfs-receive set the new
> >copy to be readonly.
> >
> >What I want to do is to use that new subvolume read/write.  The only way
> >I have figured out to do this is to create another snapshot on the new
> >volume which is NOT readonly.  I believe that means I need to keep both
> >of these subvolumes around.
> 
> As soon as I sent this I believe I found the answer.
> 
> I was sort of right about creating the new read-write (NOT readonly)
> snapshot.  After it is created simply delete the one which was created by
> btrfs-receive.

ATM, this is the way to do it. There's an ioctl to toggle the RO/RW
status of a subvolume, so it could save you one snapshot, but there's
not tool support to do that. I hope this will be possible with the
upcomming 'per-object properties' feature.

david