All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/7] btrfs: add helper btrfs_num_devices() to deduce num_devices
Date: Fri, 20 Jul 2018 19:18:54 +0800	[thread overview]
Message-ID: <d3fc6178-0884-28cf-ac3e-e42a00682150@oracle.com> (raw)
In-Reply-To: <20180719115332.GI26141@twin.jikos.cz>



On 07/19/2018 07:53 PM, David Sterba wrote:
> On Mon, Jul 16, 2018 at 10:58:11PM +0800, Anand Jain wrote:
>> When the replace is running the fs_devices::num_devices also includes
>> the replace device, however in some operations like device delete and
>> balance it needs the actual num_devices without the repalce devices, so
>> now the function btrfs_num_devices() just provides that.
> 
> We can't run any two from device delete, device replace or balance at
> the same time.
> 
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>> v2: add comments. Thanks Nikolay.
>>
>>   fs/btrfs/volumes.c | 32 ++++++++++++++++++--------------
>>   1 file changed, 18 insertions(+), 14 deletions(-)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 0f4c512aa6b4..1c0b56374992 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -1844,6 +1844,21 @@ void btrfs_assign_next_active_device(struct btrfs_fs_info *fs_info,
>>   		fs_info->fs_devices->latest_bdev = next_device->bdev;
>>   }
>>   
>> +/* Returns btrfs_fs_devices::num_devices excluding replace device if any */
>> +static inline u64 btrfs_num_devices(struct btrfs_fs_info *fs_info)
>> +{
>> +	u64 num_devices = fs_info->fs_devices->num_devices;
>> +
>> +	btrfs_dev_replace_read_lock(&fs_info->dev_replace);
>> +	if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace)) {
>> +		WARN_ON(num_devices < 1);
>> +		num_devices--;
>> +	}
>> +	btrfs_dev_replace_read_unlock(&fs_info->dev_replace);



> This does not make sense, besides that > btrfs_dev_replace_is_ongoing is
> always going to be false here,

  No. There is a way how balance and replace could co-exists.
  (theoretically, I didn't experiment it yet)
  . Start balance and pause it
  . Now start the replace
  . power-fail
  . The open_ctree() first starts the balance so it must check
  for the replace device otherwise our num_devices calculation will
  be wrong. IMO its not a good idea to remove the replace check here.

  For now a consolidation as in this patch is better.

Thanks, Anand


> the locking would need to cover the whole
> range where we want the num_devices to remain unchanged by other
> operatons.
> 
>> +
>> +	return num_devices;
>> +}
>> +
>>   int btrfs_rm_device(struct btrfs_fs_info *fs_info, const char *device_path,
>>   		u64 devid)
>>   {
>> @@ -1857,13 +1872,7 @@ int btrfs_rm_device(struct btrfs_fs_info *fs_info, const char *device_path,
>>   
>>   	mutex_lock(&uuid_mutex);
>>   
>> -	num_devices = fs_devices->num_devices;
>> -	btrfs_dev_replace_read_lock(&fs_info->dev_replace);
>> -	if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace)) {
>> -		WARN_ON(num_devices < 1);
>> -		num_devices--;
>> -	}
>> -	btrfs_dev_replace_read_unlock(&fs_info->dev_replace);
>> +	num_devices = btrfs_num_devices(fs_info);
>>   
>>   	ret = btrfs_check_raid_min_devices(fs_info, num_devices - 1);
>>   	if (ret)
>> @@ -3723,13 +3732,8 @@ int btrfs_balance(struct btrfs_fs_info *fs_info,
>>   		}
>>   	}
>>   
>> -	num_devices = fs_info->fs_devices->num_devices;
>> -	btrfs_dev_replace_read_lock(&fs_info->dev_replace);
>> -	if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace)) {
>> -		WARN_ON(num_devices < 1);
>> -		num_devices--;
>> -	}
>> -	btrfs_dev_replace_read_unlock(&fs_info->dev_replace);
>> +	num_devices = btrfs_num_devices(fs_info);
>> +
>>   	allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE | BTRFS_BLOCK_GROUP_DUP;
>>   	if (num_devices > 1)
>>   		allowed |= (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1);
>> -- 
>> 2.7.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  parent reply	other threads:[~2018-07-20 12:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 14:58 [PATCH 0/7] Misc volume patch set part2 Anand Jain
2018-07-16 14:58 ` [PATCH v4 1/7] btrfs: drop uuid_mutex in btrfs_free_extra_devids() Anand Jain
2018-07-16 14:58 ` [PATCH v2 2/7] btrfs: fix race between free_stale_devices and close_fs_devices Anand Jain
2018-07-16 14:58 ` [PATCH 3/7] btrfs: do device clone using the btrfs_scan_one_device Anand Jain
2018-07-19 12:31   ` David Sterba
2018-07-20  6:35     ` Anand Jain
2018-07-20  7:13       ` Anand Jain
2018-07-16 14:58 ` [PATCH 4/7] btrfs: use the assigned fs_devices instead of the dereference Anand Jain
2018-07-19 12:01   ` David Sterba
2018-07-16 14:58 ` [PATCH 5/7] btrfs: warn for num_devices below 0 Anand Jain
2018-07-23 14:01   ` David Sterba
2018-07-23 14:15     ` Anand Jain
2018-07-16 14:58 ` [PATCH 6/7] btrfs: add helper btrfs_num_devices() to deduce num_devices Anand Jain
2018-07-19 11:53   ` David Sterba
2018-07-20  1:41     ` Anand Jain
2018-07-20 11:18     ` Anand Jain [this message]
2018-07-23 13:57       ` David Sterba
2018-07-23 14:21         ` Anand Jain
2018-07-16 14:58 ` [PATCH 7/7] btrfs: add helper function check device delete able Anand Jain
2018-07-19 11:45   ` David Sterba
2018-07-20  1:34     ` Anand Jain
2018-07-20 11:22       ` Anand Jain
2018-07-16 15:27 ` [PATCH 0/7] Misc volume patch set part2 Anand Jain

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=d3fc6178-0884-28cf-ac3e-e42a00682150@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.