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
