From patchwork Tue Apr 22 16:07:09 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Brown X-Patchwork-Id: 4033621 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 D71ADBFF02 for ; Tue, 22 Apr 2014 16:05:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D3985201F7 for ; Tue, 22 Apr 2014 16:05:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AFD87201E7 for ; Tue, 22 Apr 2014 16:05:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757141AbaDVQFi (ORCPT ); Tue, 22 Apr 2014 12:05:38 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:43512 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756188AbaDVQFg (ORCPT ); Tue, 22 Apr 2014 12:05:36 -0400 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3528721476; Tue, 22 Apr 2014 12:05:35 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 22 Apr 2014 12:05:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=yjep2JdTKHGBxdEu5h1NorCEURI=; b=NRoUCQgH4Ad3POLbYlArI8IeFfpW +iGQJP0Q70CdxLdgBrcQpMwTwvTIhUc117hrsNXLWQJqf4mx3qZp4/59UXEvJDbQ HaJiNLvVrzdV3iO+Q6tvoWbjqnA+qCRXXvVZU43LsaEMoyZA+PcpZWq1i21hgYKm /HsueSqs6r4K8PU= X-Sasl-enc: JIvPNvE3PyvMR6upTUnAV0UodxiQRcAvz/vCO9CfNRL7 1398182734 Received: from davidb.org (unknown [174.129.209.85]) by mail.messagingengine.com (Postfix) with ESMTPA id E6219680135; Tue, 22 Apr 2014 12:05:34 -0400 (EDT) Date: Tue, 22 Apr 2014 09:07:09 -0700 From: David Brown To: Marc MERLIN Cc: linux-btrfs@vger.kernel.org Subject: Re: btrfs send/receive still gets out of sync in 3.14.0 Message-ID: <20140422160709.GA18265@davidb.org> References: <20140322210455.GL28005@merlins.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140322210455.GL28005@merlins.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sat, Mar 22, 2014 at 02:04:56PM -0700, Marc MERLIN wrote: >After deleting a huge directory tree in my /home subvolume, syncing >snapshots now fails with: > >ERROR: rmdir o1952777-157-0 failed. No such file or directory >Error line 156 with status 1 > > DIE: Code dump: > 153 if [[ -n "$init" ]]; then > 154 btrfs send "$src_newsnap" | $ssh btrfs receive "$dest_pool/" > 155 else > 156 btrfs send -p "$src_snap" "$src_newsnap" | $ssh btrfs receive "$dest_pool/" > 157 fi > 158 > 159 # We make a read-write snapshot in case you want to use it for a chroot > > >Is there anything useful I can provide before killing my snapshot and doing >a full sync again? I have been able to work around this by hacking up btrfs receive to ignore the rmdir. As far as I can tell (tree comparison) the resulting tree is correct. David --- 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 diff --git a/cmds-receive.c b/cmds-receive.c index d6cd3da..5bd4161 100644 --- a/cmds-receive.c +++ b/cmds-receive.c @@ -492,6 +492,9 @@ static int process_rmdir(const char *path, void *user) fprintf(stderr, "ERROR: rmdir %s failed. %s\n", path, strerror(-ret)); } + // Ugly hack to work around kernel problem of sending + // redundant rmdirs. + ret = 0; free(full_path); return ret;