From patchwork Thu Aug 9 04:12:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Misono Tomohiro X-Patchwork-Id: 10560869 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 282281057 for ; Thu, 9 Aug 2018 04:13:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0766F2A984 for ; Thu, 9 Aug 2018 04:13:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC99A2A9F7; Thu, 9 Aug 2018 04:13:35 +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 766C92A984 for ; Thu, 9 Aug 2018 04:13:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727656AbeHIGfX (ORCPT ); Thu, 9 Aug 2018 02:35:23 -0400 Received: from mgwkm02.jp.fujitsu.com ([202.219.69.169]:12440 "EHLO mgwkm02.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726926AbeHIGfX (ORCPT ); Thu, 9 Aug 2018 02:35:23 -0400 Received: from kw-mxoi1.gw.nic.fujitsu.com (unknown [192.168.231.131]) by mgwkm02.jp.fujitsu.com with smtp id 248f_1372_e44b2c8c_c693_4d8d_b538_6891dafd1331; Thu, 09 Aug 2018 13:12:31 +0900 Received: from g01jpfmpwkw03.exch.g01.fujitsu.local (g01jpfmpwkw03.exch.g01.fujitsu.local [10.0.193.57]) by kw-mxoi1.gw.nic.fujitsu.com (Postfix) with ESMTP id EA5A3AC01AC for ; Thu, 9 Aug 2018 13:12:29 +0900 (JST) Received: from G01JPEXCHKW18.g01.fujitsu.local (G01JPEXCHKW18.g01.fujitsu.local [10.0.194.57]) by g01jpfmpwkw03.exch.g01.fujitsu.local (Postfix) with ESMTP id 19653BD67EA; Thu, 9 Aug 2018 13:12:29 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.5.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20170217-enc X-SHieldMailCheckerMailID: 4cb5a9bd840c4e76917872aa35b0331f From: Misono Tomohiro Subject: [PATCH v4] btrfs: qgroup: Remove qgroup items along with subvolume deletion References: To: CC: David Sterba Message-ID: <055391ff-7137-4210-4eff-f2c3f70cf68b@jp.fujitsu.com> Date: Thu, 9 Aug 2018 13:12:25 +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: 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). Note that qgroup becomes inconsistent in following case: 1. qgroup relation exists 2. and subvolume's excl != rref In this case manual qgroup rescan is needed. Reviewed-by: Lu Fengqi Reviewed-by: Qu Wenruo Signed-off-by: Misono Tomohiro --- Hi David, It turned out that this patch may cause qgroup inconsistency in case described above and need manual rescan. Since current code will keep qgroup items but not break qgroup consistency when deleting subvolume, I cannot clearly say which behavior is better for qgroup usability. Can I ask your opinion? v3 -> v4: Check return value of btrfs_remove_qgroup() and if it is 1, print message in syslog that fs needs qgroup rescan fs/btrfs/extent-tree.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 9e7b237b9547..828d9e68047d 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,20 @@ int btrfs_drop_snapshot(struct btrfs_root *root, btrfs_put_fs_root(root); } root_dropped = true; + + /* Remove level-0 qgroup items since no other subvolume can use them */ + ret = btrfs_remove_qgroup(trans, objectid); + if (ret == 1) { + /* This means qgroup becomes inconsistent by removing items */ + btrfs_info(fs_info, + "qgroup inconsistency found, need qgroup rescan"); + } else if (ret == -EINVAL || ret == -ENOENT) { + /* qgroup is not enabled or 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: