Btrfs devel - Nov 2013 - btrfs send size

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!
--
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

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

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