btrfs send size

btrfs send size

[Jim Salter]

Hi list -

Long time ZFS guy here trying to move everything over from ZFS to btrfs, 
which entails a lot of re-scripting and re-learning.

Question of the day: how can I determine the size of a btrfs send 
operation before hand?  I'd like to be able to provide a progress bar 
(I'm accustomed to using pv to do this), but I would need to know a 
rough approximation at least of how much data I'm going to transfer in 
order to be able to do that.

Under ZFS, you can do this:

root@box:~# zfs send -nvi 
data/images@autosnap_2013-11-27_14:00:01_hourly 
data/images@autosnap_2013-11-27_15:00:01_hourly
send from @autosnap_2013-11-27_14:00:01_hourly to 
data/images@autosnap_2013-11-27_15:00:01_hourly estimated size is 42.7M
total estimated size is 42.7M

Which then lets me do this:

root@box:~# zfs send -i data/images@autosnap_2013-11-27_14:00:01_hourly 
data/images@autosnap_2013-11-27_15:00:01_hourly | pv -s 42.7M | ssh 
otherbox zfs receive backup/images

And get a nice progress bar.

I can't find a manpage for the btrfs command that lists ANY information 
about btrfs send, and I haven't found anything online about doing a size 
check on send operations without actually sending the data.  Anybody got 
any help for this?  This is officially a Big Deal for those of us who 
customarily do asynchronous replication, so it would be really, really 
awesome if this could get addressed. =)

Thank you!

Re: btrfs send size

[Duncan]

Jim Salter posted on Wed, 27 Nov 2013 15:09:18 -0500 as excerpted:

> I can't find a manpage for the btrfs command that lists ANY information
> about btrfs send, and I haven't found anything online about doing a size
> check on send operations without actually sending the data.  Anybody got
> any help for this?  This is officially a Big Deal for those of us who
> customarily do asynchronous replication, so it would be really, really
> awesome if this could get addressed. =)

You're not using a current btrfs-progs version (3.12 being current as of 
just a couple days ago, when Chris tagged it and announced versions 
synced to kernel versions, now), then.

btrfs --version
Btrfs v3.12

>From the btrfs (8) manpage:

>>>>

send [-v] [-p <parent>] [-c <clone-src>] [-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, use '-p <parent>'.  If you want to allow btrfs to clone 
from any additional local snapshots, use '-c <clone-src>' (multiple times 
where applicable).  You must not specify clone sources unless you 
guarantee that these snapshots are exactly in the same state on both 
sides, the sender and the receiver.  It is allowed to omit the which case 
'btrfs send' will determine a suitable parent among the clone sources 
itself.

Options

-v   Enable verbose debug output. Each occurrence of this option 	
increases the verbose level more.
       
-p <parent>
Send an incremental stream from <parent> to <subvol>.
       
-c <clone-src>
Use this snapshot as a clone source for an incremental send (multiple 
allowed).
       
-f <outfile>
Output is normally written to stdout. To write to a file, use this option.
An alternative would be to use pipes.
       
<<<<

Seems that last sentence before the options had something chopped out, 
but that's what the manpage says.

FWIW I don't use btrfs send here so I can't vouch for the accuracy of the 
above, but that's what's in the latest manpage, anyway.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman