From patchwork Sun Apr 6 00:18:38 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc MERLIN X-Patchwork-Id: 3942971 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BE01ABFF02 for ; Sun, 6 Apr 2014 00:18:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B7B3F20377 for ; Sun, 6 Apr 2014 00:18:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 80CB420364 for ; Sun, 6 Apr 2014 00:18:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753705AbaDFASq (ORCPT ); Sat, 5 Apr 2014 20:18:46 -0400 Received: from magic.merlins.org ([209.81.13.136]:58271 "EHLO mail1.merlins.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753591AbaDFASp (ORCPT ); Sat, 5 Apr 2014 20:18:45 -0400 Received: from svh-gw.merlins.org ([173.11.111.145]:42592 helo=legolas.merlins.org) by mail1.merlins.org with esmtpsa (Cipher TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80 #2) id 1WWanF-0003SZ-N7 by authid with srv_auth_plain; Sat, 05 Apr 2014 17:18:44 -0700 Received: from merlin by legolas.merlins.org with local (Exim 4.80) (envelope-from ) id 1WWanG-0000L9-6w; Sat, 05 Apr 2014 17:18:38 -0700 Date: Sat, 5 Apr 2014 17:18:38 -0700 From: Marc MERLIN To: Filipe David Borba Manana Cc: linux-btrfs@vger.kernel.org Message-ID: <20140406001838.GA9485@merlins.org> References: <1396624841-1363-1-git-send-email-fdmanana@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1396624841-1363-1-git-send-email-fdmanana@gmail.com> X-Sysadmin: BOFH X-URL: http://marc.merlins.org/ User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 173.11.111.145 X-SA-Exim-Mail-From: marc@merlins.org X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Subject: Re: [RFC PATCH] Btrfs: send, add calculate data size flag to allow for progress estimation Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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: 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 --- 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) {