From patchwork Sat Feb 8 15:46:36 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Shilong X-Patchwork-Id: 3610411 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 944B0BF418 for ; Sat, 8 Feb 2014 15:48:52 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B7FCE20163 for ; Sat, 8 Feb 2014 15:48:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D3AEA2011D for ; Sat, 8 Feb 2014 15:48:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751831AbaBHPsr (ORCPT ); Sat, 8 Feb 2014 10:48:47 -0500 Received: from mail-pb0-f51.google.com ([209.85.160.51]:33273 "EHLO mail-pb0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751826AbaBHPsq (ORCPT ); Sat, 8 Feb 2014 10:48:46 -0500 Received: by mail-pb0-f51.google.com with SMTP id un15so4491889pbc.38 for ; Sat, 08 Feb 2014 07:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=4r8niCYoJJKWNrcZEeNsIG6qIfFlTGRia+zkwGD4tcU=; b=PZRFPX382eexztvMjxv7rpcIzhdErILdcS9ZZoYo8jhxnf/al8C8+3yHNMN97lk+RV zcbkATyfQor+JqlxajJRavNOvQU+JnLThC2f3urK+a/JOk2xAQv5SEkAKS/OtY6Pwl8H FpKjtmaRv4CjhYhKNL/sg9krgmvNpWYMWq2IqD7CPkzL7bEdDOX7Q20AzYYmy2t/fvg0 WYKEP9yZN66SfYtblrzYgMrVuexQKi73vVo2it1sNEyzhHtJQETP2Sm+r/Dnsx1W33IR GKVcPqHFYYQHfHvtpOTYWRBEFl0oO+Z7AUVOErs2tMKwCFYe/g6n5/StQbAQ3yoA/yqa BU4Q== X-Received: by 10.66.182.199 with SMTP id eg7mr14837400pac.135.1391874526073; Sat, 08 Feb 2014 07:48:46 -0800 (PST) Received: from linux-b0ol.site ([223.65.140.111]) by mx.google.com with ESMTPSA id hb10sm24763222pbd.1.2014.02.08.07.48.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2014 07:48:45 -0800 (PST) From: Wang Shilong To: linux-btrfs@vger.kernel.org Cc: Wang Shilong , Josef Bacik Subject: [RFC PATCH 2/2] Revert "Btrfs: remove transaction from btrfs send" Date: Sat, 8 Feb 2014 23:46:36 +0800 Message-Id: <1391874396-2273-2-git-send-email-wangshilong1991@gmail.com> X-Mailer: git-send-email 1.8.4 In-Reply-To: <1391874396-2273-1-git-send-email-wangshilong1991@gmail.com> References: <1391874396-2273-1-git-send-email-wangshilong1991@gmail.com> 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.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, 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 From: Wang Shilong This reverts commit 41ce9970a8a6a362ae8df145f7a03d789e9ef9d2. Previously i was thinking we can use readonly root's commit root safely while it is not true, readonly root may be cowed with the following cases. 1.snapshot send root will cow source root. 2.balance,device operations will also cow readonly send root to relocate. So i have two ideas to make us safe to use commit root. -->approach 1: make it protected by transaction and end transaction properly and we research next item from root node(see btrfs_search_slot_for_read()). -->approach 2: add another counter to local root structure to sync snapshot with send. and add a global counter to sync send with exclusive device operations. So with approach 2, send can use commit root safely, because we make sure send root can not be cowed during send. Unfortunately, it make codes *ugly* and more complex to maintain. To make snapshot and send exclusively, device operations and send operation exclusively with each other is a little confusing for common users. So why not drop into previous way. Cc: Josef Bacik Signed-off-by: Wang Shilong --- Josef, if we reach agreement to adopt this approach, please revert Filipe's patch(Btrfs: make some tree searches in send.c more efficient) from btrfs-next. --- fs/btrfs/send.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index 168b9ec..e9d1265 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -5098,6 +5098,7 @@ out: static int full_send_tree(struct send_ctx *sctx) { int ret; + struct btrfs_trans_handle *trans = NULL; struct btrfs_root *send_root = sctx->send_root; struct btrfs_key key; struct btrfs_key found_key; @@ -5119,6 +5120,19 @@ static int full_send_tree(struct send_ctx *sctx) key.type = BTRFS_INODE_ITEM_KEY; key.offset = 0; +join_trans: + /* + * We need to make sure the transaction does not get committed + * while we do anything on commit roots. Join a transaction to prevent + * this. + */ + trans = btrfs_join_transaction(send_root); + if (IS_ERR(trans)) { + ret = PTR_ERR(trans); + trans = NULL; + goto out; + } + /* * Make sure the tree has not changed after re-joining. We detect this * by comparing start_ctransid and ctransid. They should always match. @@ -5142,6 +5156,19 @@ static int full_send_tree(struct send_ctx *sctx) goto out_finish; while (1) { + /* + * When someone want to commit while we iterate, end the + * joined transaction and rejoin. + */ + if (btrfs_should_end_transaction(trans, send_root)) { + ret = btrfs_end_transaction(trans, send_root); + trans = NULL; + if (ret < 0) + goto out; + btrfs_release_path(path); + goto join_trans; + } + eb = path->nodes[0]; slot = path->slots[0]; btrfs_item_key_to_cpu(eb, &found_key, slot); @@ -5169,6 +5196,12 @@ out_finish: out: btrfs_free_path(path); + if (trans) { + if (!ret) + ret = btrfs_end_transaction(trans, send_root); + else + btrfs_end_transaction(trans, send_root); + } return ret; }