Re: [PATCH] Btrfs-progs: do not add stale device into fs_devices

[Anand Jain <anand.jain@oracle.com>]

On 10/11/2017 05:33 PM, Nikolay Borisov wrote:
> 
> 
> On 11.10.2017 03:28, Liu Bo wrote:
>> If one of btrfs's devices was pulled out and we've replaced it with a
>> new one, then they have the same uuid.
>>
>> If that device gets reconnected, 'btrfs filesystem show' will show the
>> stale one instead of the new one, but on kernel side btrfs has a fix
>> to not include the stale one, this could confuse users as people may
>> monitor btrfs by running that cli.
>>
>> This does the similar thing to what kernel side has done.
>>
>> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
>> ---
>>   volumes.c | 15 ++++++++++++++-
>>   1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/volumes.c b/volumes.c
>> index 2f3943d..c7b7a41 100644
>> --- a/volumes.c
>> +++ b/volumes.c
>> @@ -138,7 +138,20 @@ static int device_list_add(const char *path,
>>   		list_add(&device->dev_list, &fs_devices->devices);
>>   		device->fs_devices = fs_devices;
>>   	} else if (!device->name || strcmp(device->name, path)) {
>> -		char *name = strdup(path);
>> +		char *name;
>> +
>> +		/*
>> +		 * The existing device has newer generation, so this
>> +		 * one could be a stale one, don't add it.
>> +		 */
>> +		if (found_transid < device->generation) {
>> +			warning("adding device %s gen %llu but found a existing device %s gen %llu\n",
>> +				path, found_transid, device->name,
>> +				device->generation, found_transid);
> 
> You pass in 5 parameters but have only 4 formatting strings. I don't see
> the same happening on other warning() invocations? Perhaps the last
> found_transid is not necessary?

  I missed that. Sorry.

Thanks, Anand


>> +			return -EEXIST;
>> +		}
>> +
>> +		name = strdup(path);
>>                   if (!name)
>>                           return -ENOMEM;
>>                   kfree(device->name);
>>
> --
> 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
>