From patchwork Thu Aug 9 07:05:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Misono Tomohiro X-Patchwork-Id: 10561009 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C4D7C13BB for ; Thu, 9 Aug 2018 07:05:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AAEF429CD9 for ; Thu, 9 Aug 2018 07:05:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9F94A29ED2; Thu, 9 Aug 2018 07:05:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 23EBE29DDB for ; Thu, 9 Aug 2018 07:05:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728830AbeHIJ3Q (ORCPT ); Thu, 9 Aug 2018 05:29:16 -0400 Received: from mgwym01.jp.fujitsu.com ([211.128.242.40]:50518 "EHLO mgwym01.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728582AbeHIJ3Q (ORCPT ); Thu, 9 Aug 2018 05:29:16 -0400 Received: from yt-mxoi2.gw.nic.fujitsu.com (unknown [192.168.229.69]) by mgwym01.jp.fujitsu.com with smtp id 0491_6901_7690cc06_7057_48b2_80c1_b8ae658793af; Thu, 09 Aug 2018 16:05:41 +0900 Received: from g01jpfmpwkw03.exch.g01.fujitsu.local (g01jpfmpwkw03.exch.g01.fujitsu.local [10.0.193.57]) by yt-mxoi2.gw.nic.fujitsu.com (Postfix) with ESMTP id DDBA9AC0096 for ; Thu, 9 Aug 2018 16:05:41 +0900 (JST) Received: from G01JPEXCHKW15.g01.fujitsu.local (G01JPEXCHKW15.g01.fujitsu.local [10.0.194.54]) by g01jpfmpwkw03.exch.g01.fujitsu.local (Postfix) with ESMTP id D6C54BD67EC; Thu, 9 Aug 2018 16:05:40 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.5.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20170217-enc X-SHieldMailCheckerMailID: 8aef46608a954533b55ec36464046d9a Subject: [PATCH v5] btrfs: qgroup: Remove qgroup items along with subvolume deletion From: Misono Tomohiro To: CC: David Sterba , Qu Wenruo References: <055391ff-7137-4210-4eff-f2c3f70cf68b@jp.fujitsu.com> Message-ID: <1b5d9d72-5e6b-a88b-0192-8676a19b9732@jp.fujitsu.com> Date: Thu, 9 Aug 2018 16:05:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <055391ff-7137-4210-4eff-f2c3f70cf68b@jp.fujitsu.com> Content-Language: en-US X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable 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 When qgroup is on, subvolume deletion does not remove qgroup items of the subvolume (qgroup info, limit, relation) from quota tree and they need to get removed manually by "btrfs qgroup destroy". Since level 0 qgroup cannot be used/inherited by any other subvolume, let's remove them automatically when subvolume is deleted (to be precise, when the subvolume root is dropped). Signed-off-by: Misono Tomohiro --- v4 -> v5: Commit current transaction before calling btrfs_remove_qgroup() to keep qgroup consistency in all case. This resolves the concern in v4 path and there should be no demerit in this patch. fs/btrfs/extent-tree.c | 45 +++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 41 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 9e7b237b9547..ed052105e741 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -8871,12 +8871,13 @@ int btrfs_drop_snapshot(struct btrfs_root *root, struct btrfs_root_item *root_item = &root->root_item; struct walk_control *wc; struct btrfs_key key; + u64 objectid = root->root_key.objectid; int err = 0; int ret; int level; bool root_dropped = false; - btrfs_debug(fs_info, "Drop subvolume %llu", root->objectid); + btrfs_debug(fs_info, "Drop subvolume %llu", objectid); path = btrfs_alloc_path(); if (!path) { @@ -9030,7 +9031,7 @@ int btrfs_drop_snapshot(struct btrfs_root *root, goto out_end_trans; } - if (root->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID) { + if (objectid != BTRFS_TREE_RELOC_OBJECTID) { ret = btrfs_find_root(tree_root, &root->root_key, path, NULL, NULL); if (ret < 0) { @@ -9043,8 +9044,7 @@ int btrfs_drop_snapshot(struct btrfs_root *root, * * The most common failure here is just -ENOENT. */ - btrfs_del_orphan_item(trans, tree_root, - root->root_key.objectid); + btrfs_del_orphan_item(trans, tree_root, objectid); } } @@ -9056,6 +9056,43 @@ int btrfs_drop_snapshot(struct btrfs_root *root, btrfs_put_fs_root(root); } root_dropped = true; + + if (test_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags)) { + /* + * Remove level-0 qgroup items since no other subvolume can + * use them. + * + * First, commit current transaction in order to make sure + * this subvolume's excl == rfer == 0. Otherwise removing + * qgroup relation causes qgroup inconsistency if excl != rfer. + */ + ret = btrfs_commit_transaction(trans); + if (ret) + goto out_free; + + /* Start new transaction and remove qgroup items */ + trans = btrfs_start_transaction(tree_root, 0); + if (IS_ERR(trans)) { + err = PTR_ERR(trans); + goto out_free; + } + + ret = btrfs_remove_qgroup(trans, objectid); + if (ret == 1) { + /* + * This means qgroup becomes inconsistent + * (should not happen since we did transaction commit) + */ + btrfs_warn(fs_info, + "qgroup inconsistency found, need qgroup rescan"); + } else if (ret == -EINVAL || ret == -ENOENT) { + /* qgroup is already removed, just ignore this */ + } else if (ret) { + btrfs_abort_transaction(trans, ret); + err = ret; + } + } + out_end_trans: btrfs_end_transaction_throttle(trans); out_free: