Adam Ryczkowski
2013-Feb-03 13:33 UTC
Is it possible to use send & receive features to clone the btrfs partition efficiently (including all snapshots inside)?
It is very difficult for me to find any good documentation on send & receive commands. Event the most recent btrfs progs man page (accessed from git today) says nothing. I want to migrate data (including numerous read only snaphots) from linux-raid - based storage into a native raid btrfs. I think that cloning via send & receive is a viable option. Can anyone help me please? I''ve posted my question also on stackexchange: http://unix.stackexchange.com/questions/63528/how-to-clone-btrfs-filesystem-into-different-medium-preserving-snapshots-sharin . I will post the answer there, so everyone can benefit from it. Thank you, Adam Ryczkowski +48505919892 <callto:+48505919892> Skype:sisteczko <skype:sisteczko> -- 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
Chen Yang
2013-Feb-04 01:12 UTC
Re: Is it possible to use send & receive features to clone the btrfs partition efficiently (including all snapshots inside)?
> It is very difficult for me to find any good documentation on send & receive commands. Event the most recent btrfs progs man page (accessed from git today) says nothing. > > I want to migrate data (including numerous read only snaphots) from linux-raid - based storage into a native raid btrfs. > > I think that cloning via send & receive is a viable option. > > Can anyone help me please? I''ve posted my question also on stackexchange: http://unix.stackexchange.com/questions/63528/how-to-clone-btrfs-filesystem-into-different-medium-preserving-snapshots-sharin . I will post the answer there, so everyone can benefit from it. > > Thank you, > > Adam Ryczkowski > +48505919892 <callto:+48505919892> > Skype:sisteczko <skype:sisteczko> > > -- > 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 >usage: btrfs send [-v] [-i <subvol>] [-p <parent>] [-f <outfile>] <subvol> Send the subvolume to stdout. Sends the subvolume specified by <subvol> to stdout. By default, this will send the whole subvolume. To do an incremental send, one or multiple ''-i <clone_source>'' arguments have to be specified. A ''clone source'' is a subvolume that is known to exist on the receiving side in exactly the same state as on the sending side. Normally, a good snapshot parent is searched automatically in the list of ''clone sources''. To override this, use ''-p <parent>'' to manually specify a snapshot parent. A manually specified snapshot parent is also regarded as ''clone source''. -v Enable verbose debug output. Each occurrence of this option increases the verbose level more. -i <subvol> Informs btrfs send that this subvolume, can be taken as ''clone source''. This can be used for incremental sends. -p <subvol> Disable automatic snapshot parent determination and use <subvol> as parent. This subvolume is also added to the list of ''clone sources'' (see -i). -f <outfile> Output is normally written to stdout. To write to a file, use this option. An alternative would be to use pipes. usage: btrfs receive [-v] [-f <infile>] <mount> Receive subvolumes from stdin. Receives one or more subvolumes that were previously sent with btrfs send. The received subvolumes are stored into <mount>. btrfs receive will fail in case a receiving subvolume already exists. It will also fail in case a previously received subvolume was changed after it was received. After receiving a subvolume, it is immediately set to read only. -v Enable verbose debug output. Each occurrence of this option increases the verbose level more. -f <infile> By default, btrfs receive uses stdin to receive the subvolumes. Use this option to specify a file to use instead. -- 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
Adam Ryczkowski
2013-Feb-16 22:07 UTC
Why does "btrfs send /mnt/btrfs-root" fail with "ERROR: /mnt/btrfs-root is not read-only." even when mounted with option "ro"?
Question as in title. I did remount my btrfs partition as read-only (i.e. I did "sudo mount /dev/sda9 /mnt/btrfs-root -o ro") And when I did btrfs send /mnt/btrfs-root >/dev/null I received "ERROR: /mnt/adama-docs is not read-only." Although, when I sudo touch /mnt/btrfs-root/foo I get "touch: cannot touch `/mnt/btrfs-root/foo'': Read-only file system" My btrfs --version reads Btrfs v0.20-rc1-56-g6cd836d And uname -r 3.7.8-030708-generic Do I miss something obvious? Or should I wait until next kernel version? -- Adam Ryczkowski +48505919892 Skype:sisteczko -- 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
Hugo Mills
2013-Feb-16 22:17 UTC
Re: Why does "btrfs send /mnt/btrfs-root" fail with "ERROR: /mnt/btrfs-root is not read-only." even when mounted with option "ro"?
On Sat, Feb 16, 2013 at 11:07:28PM +0100, Adam Ryczkowski wrote:> Question as in title. > > I did remount my btrfs partition as read-only > > (i.e. I did "sudo mount /dev/sda9 /mnt/btrfs-root -o ro") > > And when I did > btrfs send /mnt/btrfs-root >/dev/null > I received "ERROR: /mnt/adama-docs is not read-only." > > Although, when I > sudo touch /mnt/btrfs-root/foo > I get "touch: cannot touch `/mnt/btrfs-root/foo'': Read-only file system" > > > My btrfs --version reads > Btrfs v0.20-rc1-56-g6cd836d > > And uname -r > 3.7.8-030708-generic > > Do I miss something obvious? Or should I wait until next kernel version?You need to make a read-only snapshot with the -r option to btrfs sub snap. This is independent of the mount options, and prevents the resulting subvolume from being modified during the send operation. The error message isn''t obvious, and should probably be improved. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- If it''s December 1941 in Casablanca, what time is it --- in New York?
On Sun, Feb 17, 2013 at 12:14:30AM +0100, Adam Ryczkowski wrote:> Welcome, > > I need to clone btrfs partition. Not a single snapshot, but the > whole lot of snapshots. > > I thought that send & receive can help me. Can it? When I try to use > > btrfs send /mnt/btrfs-root >/dev/null > > I get "ERROR: /mnt/adama-docs is not read-only.", and I was > explained that I need to use snaphot (created with the "-r" switch). > > So does it mean that I need to make a recursive search for each > read&write subvolume on the file system in order to make a read-only > snapshot, so I can clone the whole partition? Or is there a more > simple approach?Right now, yes, that''s what you''ll have to do. Note that the set of snapshots won''t be atomic, although each snapshot itself is atomic. Recursive snapshots aren''t implemented yet, but are on the list of things to do. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I know of three kinds: hot, --- cool, and what-time-does-the-tune-start?
Welcome, I need to clone btrfs partition. Not a single snapshot, but the whole lot of snapshots. I thought that send & receive can help me. Can it? When I try to use btrfs send /mnt/btrfs-root >/dev/null I get "ERROR: /mnt/adama-docs is not read-only.", and I was explained that I need to use snaphot (created with the "-r" switch). So does it mean that I need to make a recursive search for each read&write subvolume on the file system in order to make a read-only snapshot, so I can clone the whole partition? Or is there a more simple approach? -- Adam Ryczkowski +48505919892 Skype:sisteczko -- 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