Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:43758 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753638AbcFEWDL (ORCPT ); Sun, 5 Jun 2016 18:03:11 -0400 Subject: Patch "Btrfs: do not create empty block group if we have allocated data" has been added to the 4.5-stable tree To: bo.li.liu@oracle.com, dsterba@suse.com, gregkh@linuxfoundation.org Cc: , From: Date: Sun, 05 Jun 2016 14:48:07 -0700 Message-ID: <146516328713652@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled Btrfs: do not create empty block group if we have allocated data to the 4.5-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: btrfs-do-not-create-empty-block-group-if-we-have-allocated-data.patch and it can be found in the queue-4.5 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From cf25ce518e8ef9d59b292e51193bed2b023a32da Mon Sep 17 00:00:00 2001 From: Liu Bo Date: Mon, 14 Dec 2015 18:29:32 -0800 Subject: Btrfs: do not create empty block group if we have allocated data From: Liu Bo commit cf25ce518e8ef9d59b292e51193bed2b023a32da upstream. Now we force to create empty block group to keep data profile alive, however, in the below example, we eventually get an empty block group while we're trying to get more space for other types (metadata/system), - Before, block group "A": size=2G, used=1.2G block group "B": size=2G, used=512M - After "btrfs balance start -dusage=50 mount_point", block group "A": size=2G, used=(1.2+0.5)G block group "C": size=2G, used=0 Since there is no data in block group C, it won't be deleted automatically and we have to get the unused 2G until the next mount. Balance itself just moves data and doesn't remove data, so it's safe to not create such a empty block group if we already have data allocated in other block groups. Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/volumes.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -3401,6 +3401,7 @@ static int __btrfs_balance(struct btrfs_ u32 count_meta = 0; u32 count_sys = 0; int chunk_reserved = 0; + u64 bytes_used = 0; /* step one make some room on all the devices */ devices = &fs_info->fs_devices->devices; @@ -3539,7 +3540,13 @@ again: goto loop; } - if ((chunk_type & BTRFS_BLOCK_GROUP_DATA) && !chunk_reserved) { + ASSERT(fs_info->data_sinfo); + spin_lock(&fs_info->data_sinfo->lock); + bytes_used = fs_info->data_sinfo->bytes_used; + spin_unlock(&fs_info->data_sinfo->lock); + + if ((chunk_type & BTRFS_BLOCK_GROUP_DATA) && + !chunk_reserved && !bytes_used) { trans = btrfs_start_transaction(chunk_root, 0); if (IS_ERR(trans)) { mutex_unlock(&fs_info->delete_unused_bgs_mutex); Patches currently in stable-queue which might be from bo.li.liu@oracle.com are queue-4.5/btrfs-fix-unexpected-return-value-of-fiemap.patch queue-4.5/btrfs-do-not-create-empty-block-group-if-we-have-allocated-data.patch queue-4.5/btrfs-fix-divide-error-upon-chunk-s-stripe_len.patch