Re: [PATCH] btrfs: resize: Allow user to shrink missing device

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

On 11/19/19 10:34 PM, David Sterba wrote:
> On Tue, Nov 19, 2019 at 03:40:42PM +0800, Anand Jain wrote:
>>    IMO changing the size of the missing device is point less. What if
>>    in between the resize and replace the missing device reappears
>>    in the following unmount and mount.
> 
> The reappearing device is always tricky. If the device is missing from
> the beginning, it'll exist in the fs_devices structure with MISSING bit
> set. If it reappears, device_list_add will find it, update the path and
> drop the missing bit.

  Right.

>  From that point the device is regular but might miss some data updates.

  Um no its not regular yet. If the device has reappeared after mount it
  won't be part of the dev_alloc_list, so no new chunks are allocated
  on it. It needs patch [1] to be regular but as I said in other
  thread its better not to do that unless writehole is fixed.
   [1] [PATCH] btrfs: handle dynamically reappearing missing device

> There's a check for last generation of the device to pick the latest
> one, but this applies only to mount.

  This will work as long as there is only one umount mount sequence.
  A umount mount sequence of two times will make generation on all disks
  equal including device with missing some data. But that's fine..

> Now when there's a replace in progress, and on a redundant profile, like
> in the reported case, the device can be used as source device as long as
> the data are not stale. This is detected by generation mismatch.

  Right. Reading dev_items are safe as they are read from the tree.
  (Just off topic - but non-inline file data are not so lucky in this
  scenario as they are read off-tree and there is no header, ML patch:
  "[PATCH] fstests: btrfs test read from disks of different generation"
  reproduced it).

> The resize of missing device happens on the in-memory structure as it is
> represented in the fs_devices list, before the device reappears. And
> after it's scanned again, the device item in memory is not changed, so
> the size stays and is used until replace finishes.

  Right, I checked it, it looks safe now. Thanks for verifying it.

> Which is IMO all ok for the usecase, but the device states are tricky so
> I could have missed something.

  Missing device state was only relevant here.. I can't think of any
  other.

Thanks, Anand