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 -- 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 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 -- 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 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-- 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 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-- 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 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 -- 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 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
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 -- 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 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 -- 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 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 MurphyInteresting; 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 -- 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 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-- 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 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 -- 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