Re: [PATCH v4 3/4] btrfs: add device major-minor info in the struct btrfs_device

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

On 12/01/2022 01:18, Goffredo Baroncelli wrote:
> On 11/01/2022 06.27, Anand Jain wrote:
>>
>>>> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
>>>> index 76215de8ce34..ebfe5dc73e26 100644
>>>> --- a/fs/btrfs/volumes.h
>>>> +++ b/fs/btrfs/volumes.h
>>>> @@ -73,6 +73,8 @@ struct btrfs_device {
>>>>       /* the mode sent to blkdev_get */
>>>>       fmode_t mode;
>>>> +    /* Device's major-minor number */
>>>> +    dev_t devt;
>>>
>>> What is the relation between
>>>
>>>      device->devt
>>>
>>> and
>>>
>>>      device->bdev->bd_dev
>>>
>>> ?
>>
>>   Both are same. device->bdev gets an update at the time device open. 
>> Otherwise, it is null.
>>
>>> I assumed that there are situation where there is no a device 
>>> connected to a btrfs_device
>>> structure (e.g. a degraded mounted filesystem where a device is 
>>> missing); in this case
>>> does devt == 0 ?
>>
>>   Even for the missing device we do call add_missing_dev() -> 
>> btrfs_alloc_device() that will ensure devt == 0.
>>
>>> But are there cases where devt != 0 (a device is associated to a 
>>> block device structure) and bdev == NULL ?
>>
>>   It is possible- When we unmount, the btrfs_device continues to exist 
>> and, both device->name and device->devt shall not be NULL/0; However, 
>> device->bdev will be NULL; If the device is scanned again with a 
>> different uuid, then the free_stale_device() is called to check and 
>> free the old/stale struct btrfs_device.
> 
> Ok, I think that this case (where devt!=0 and bdev==NULL) should be 
> inserted as comment in the structure before the devt field.

I will add but, did you find any pitfall for breaking such a case?
Or are you submitting any patch based on this rule?