On Fri, Apr 04, 2014 at 04:20:41PM +0100, Filipe David Borba Manana wrote:
> This new send flag makes send calculate first the amount of new file data (in bytes)
> the send root has relatively to the parent root, or for the case of a non-incremental
> send, the total amount of file data we will send through the send stream. In other words,
> it computes the sum of the lengths of all write and clone operations that will be sent
> through the send stream.
Thanks for this patch, much appreciated.
A few questions:
1) I tried to apply to 3.14.0, and it all applied except one line:
--- fs/btrfs/send.c
+++ fs/btrfs/send.c
@@ -3091,6 +3121,8 @@
int ret;
u64 ancestor = 0;
+ ASSERT(sctx->phase != SEND_PHASE_COMPUTE_DATA_SIZE);
+
name = fs_path_alloc();
from_path = fs_path_alloc();
if (!name || !from_path) {
I looked around and found nothing that looked similar enough.
Obviously it's an assert, so I can run without it, but my source being
very different from yours just made me want to check that this was most
likely ok to run with 3.14.0.
2) I saw the concerns about protocol incompatibility. Is it an issue if you run without -o
too?
3) Do you have a patch for btrfs-tools so that I can try it, or a git
tree of btrfs-tools with this that I should pull?
4) Can I run btrfs send -o snap1 snap2 >/dev/null to get quick stats
on the changes between the 2 snapshots, or is it still going to walk
through all the data blocks and send them to /dev/null afterwards?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
