Re: Unable to mount multiple subvolumes of a single disk

[Chris Mason <clm@fb.com>]

On 09/17/2014 05:47 AM, Anand Jain wrote:
> 
> Hi Chris,
> 
> 
>>> -------
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>> index e9676a4..1224b61 100644
>>> --- a/fs/btrfs/volumes.c
>>> +++ b/fs/btrfs/volumes.c
>>> @@ -533,7 +533,7 @@ static noinline int device_list_add(const char
>>> *path,
>>>                   * the btrfs dev scan cli, after FS has been mounted.
>>>                   */
>>>                  if (fs_devices->opened) {
>>> -                       return -EBUSY;
>>> +                       goto out;
>>>                  } else {
>>>                          /*
>>>                           * That is if the FS is _not_ mounted and if
>>> you
>>> @@ -566,6 +566,7 @@ static noinline int device_list_add(const char
>>> *path,
>>>          if (!fs_devices->opened)
>>>                  device->generation = found_transid;
>>>
>>> +out:
>>>          *fs_devices_ret = fs_devices;
>>>
>>>          return ret;
>>
>> Anand, are you planning on sending a full patch out for this?  One
>> concern
>> I have is that after the device_list_add call:
>>
>>
>>      if (!ret && fs_devices_ret)
>>              (*fs_devices_ret)->total_devices = total_devices;
>>
>> We should only be doing this from the newest super, not blindly
>> overwriting.
>> But that's a merge window fix.  For now I just want to deal with the
>> regression,
>> and your patch above looks good.
>>
>> Thanks for jumping on this one.
> 
> 
>  Sorry for the trouble.
>  yes, I will be sending a full patch. I am finding too difficult
>  to revive the function btrfs_scan_one_device() which is predominately
>  to handle device scan and list_update _before_ any mount. Further
>  to the concern which you mention above, there is Ioctl
>  BTRFS_IOC_DEV_READY also using this function, which absolutely should
>  not have any intention to update the device list, but it does ..
>  theoretically. And I note that this ioctl is used by systemd as well.
>  So the fix is getting a bit complicated. I am attempting.

No problem, the original patch looked right to me too.  We're getting
closer to rc6, I think at this point I'll revert the original patch
until the next merge window.  Then we can step back and nail down
exactly what is going on.

-chris