From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs send size
Date: Thu, 28 Nov 2013 10:22:31 +0000 (UTC) [thread overview]
Message-ID: <pan$49c4c$8412de9a$240c4a4a$2eb69510@cox.net> (raw)
In-Reply-To: 5296516E.8000201@jrs-s.net
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
prev parent reply other threads:[~2013-11-28 10:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 20:09 btrfs send size Jim Salter
2013-11-28 10:22 ` Duncan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$49c4c$8412de9a$240c4a4a$2eb69510@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).