linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Cc: Chris Mason <clm@fb.com>
Subject: Re: [PATCH 1/5] btrfs: Ensure at least 1g is free for balance
Date: Fri, 26 Oct 2018 15:16:16 +0300	[thread overview]
Message-ID: <6b03ed20-4ee6-4342-c287-618343f3b8ad@suse.com> (raw)
In-Reply-To: <34b2d8ff-d4f0-63a9-eb49-c26d9b84737c@mendix.com>


(Adding Chris to CC since he is the original author of the code)

On 26.10.2018 15:09, Hans van Kranenburg wrote:
> On 10/26/18 1:43 PM, Nikolay Borisov wrote:
>> The first part of balance operation is to shrink every constituting
>> device to ensure there is free space for chunk allocation.
> 
> A very useful thing to be able to do if there's no unallocated raw disk
> space left, is use balance to rewrite some blockgroup into the free
> space of other ones.
> 
> This does not need any raw space for a chunk allocation. Requiring so
> makes it unneccesarily more complicated for users to fix the situation
> they got in.

The current logic of the code doesn't preclude this use case since if we
can't shrink we just proceed to relocation. So even if 1g is replaced
with 5eb and shrink_device always fails balancing will still proceed.

However, all of this really makes me wonder do we even need this "first
stage" code in balancing (Chris, any thoughts?).

> 
>> However, the code
>> has been buggy ever since its introduction since calculating the space to shrink
>> the device by was bounded by 1 mb. Most likely the original intention was to
>> have an upper bound of 1g and not 1m, since the largest chunk size is 1g. This 
>> means the first stage in __btrfs_balance so far has been a null op since it
>> effectively freed just a single megabyte.
>>
>> Fix this by setting an upper bound of size_to_free of 1g. 
>>
>> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
>> ---
>>  fs/btrfs/volumes.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index f435d397019e..8b0fd7bf3447 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -3467,7 +3467,7 @@ static int __btrfs_balance(struct btrfs_fs_info *fs_info)
>>  	list_for_each_entry(device, devices, dev_list) {
>>  		old_size = btrfs_device_get_total_bytes(device);
>>  		size_to_free = div_factor(old_size, 1);
>> -		size_to_free = min_t(u64, size_to_free, SZ_1M);
>> +		size_to_free = min_t(u64, size_to_free, SZ_1G);
>>  		if (!test_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state) ||
>>  		    btrfs_device_get_total_bytes(device) -
>>  		    btrfs_device_get_bytes_used(device) > size_to_free ||
>>
> 
> 

  reply	other threads:[~2018-10-26 12:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26 11:43 [PATCH 0/5] Misc cleanups in balance code Nikolay Borisov
2018-10-26 11:43 ` [PATCH 1/5] btrfs: Ensure at least 1g is free for balance Nikolay Borisov
2018-10-26 12:04   ` Qu Wenruo
2018-10-26 12:08     ` Nikolay Borisov
2018-10-26 12:32       ` Qu Wenruo
2018-10-26 12:09   ` Hans van Kranenburg
2018-10-26 12:16     ` Nikolay Borisov [this message]
2018-10-26 12:36       ` Hans van Kranenburg
2018-10-26 11:43 ` [PATCH 2/5] btrfs: Refactor btrfs_can_relocate Nikolay Borisov
2018-10-26 12:35   ` Qu Wenruo
2018-11-17  1:29   ` Anand Jain
2018-12-03 17:25     ` David Sterba
2018-12-04  6:34       ` Nikolay Borisov
2018-12-04 13:07         ` David Sterba
2018-10-26 11:43 ` [PATCH 3/5] btrfs: Remove superfluous check form btrfs_remove_chunk Nikolay Borisov
2018-10-26 12:40   ` Qu Wenruo
2018-11-16 23:57   ` Anand Jain
2018-10-26 11:43 ` [PATCH 4/5] btrfs: Sink find_lock_delalloc_range's 'max_bytes' argument Nikolay Borisov
2018-10-26 12:42   ` Qu Wenruo
2018-11-17  0:53   ` Anand Jain
2018-10-26 11:43 ` [PATCH 5/5] btrfs: Replace BUG_ON with ASSERT in find_lock_delalloc_range Nikolay Borisov
2018-10-26 12:44   ` Qu Wenruo
2018-11-17  1:02   ` Anand Jain
2018-11-16 15:18 ` [PATCH 0/5] Misc cleanups in balance code David Sterba
2018-11-16 15:36   ` Nikolay Borisov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b03ed20-4ee6-4342-c287-618343f3b8ad@suse.com \
    --to=nborisov@suse.com \
    --cc=Hans.van.Kranenburg@mendix.com \
    --cc=clm@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).