From patchwork Fri Aug 3 04:08:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Misono Tomohiro X-Patchwork-Id: 10554547 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 E49CC13BB for ; Fri, 3 Aug 2018 04:08:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D717C2C643 for ; Fri, 3 Aug 2018 04:08:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CA3232C651; Fri, 3 Aug 2018 04:08:48 +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 28F302C643 for ; Fri, 3 Aug 2018 04:08:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726509AbeHCGDG (ORCPT ); Fri, 3 Aug 2018 02:03:06 -0400 Received: from mgwkm03.jp.fujitsu.com ([202.219.69.170]:15665 "EHLO mgwkm03.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726301AbeHCGDG (ORCPT ); Fri, 3 Aug 2018 02:03:06 -0400 Received: from kw-mxq.gw.nic.fujitsu.com (unknown [192.168.231.130]) by mgwkm03.jp.fujitsu.com with smtp id 06a2_2bf9_d6207d5a_37ec_4c87_b71f_889b45313f78; Fri, 03 Aug 2018 13:08:42 +0900 Received: from g01jpfmpwkw01.exch.g01.fujitsu.local (g01jpfmpwkw01.exch.g01.fujitsu.local [10.0.193.38]) by kw-mxq.gw.nic.fujitsu.com (Postfix) with ESMTP id 79CB1AC01F4 for ; Fri, 3 Aug 2018 13:08:41 +0900 (JST) Received: from G01JPEXCHKW15.g01.fujitsu.local (G01JPEXCHKW15.g01.fujitsu.local [10.0.194.54]) by g01jpfmpwkw01.exch.g01.fujitsu.local (Postfix) with ESMTP id B156C69275E for ; Fri, 3 Aug 2018 13:08:40 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.5.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20170217-enc X-SHieldMailCheckerMailID: f48485d4e7304e13b2023507eb9637d0 From: Misono Tomohiro Subject: [PATCH] btrfs: qgroup: Remove qgroup item along with subvolume deletion To: linux-btrfs References: Message-ID: Date: Fri, 3 Aug 2018 13:08:21 +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, limits, 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. Signed-off-by: Misono Tomohiro --- I don't see any reason to keep these items after subvolume deletion, but is there something I'm missing? fs/btrfs/inode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 3f51ddc18f98..4ec60a1b53a3 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4372,6 +4372,10 @@ int btrfs_delete_subvolume(struct inode *dir, struct dentry *dentry) } } + ret = btrfs_remove_qgroup(trans, dest->root_key.objectid); + if (ret == -EINVAL || ret == -ENOENT) + ret = 0; + out_end_trans: trans->block_rsv = NULL; trans->bytes_reserved = 0;