You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More than ten devices, so that at least one isn't written to when the pool-level metadata gets written.
A version of stratisd from before #3606 .
Then, what should cause the bug, with some degree of probability:
Create a pool.
Cause some action for the pool-level metadata to be written.
Stop the pool.
Start the pool. My belief is that the following will happen:
The last_update_time() result for each BDA will be stale. Sorting of the BDAs by the last update time will yield a chosen device from which to read the metadata. Because the last update time is invalid for all, the sorting will be meaningless. After some starts and stops, fewer if the number of devices far exceeds ten, the device with the older pool-level metadata will be picked and the pool will be set up using that older pool-level metadata.
So far we haven't been able to produce this, using the easily checked filesystem limit as a canary and twenty test devices.
If, at this point, the BDAs are stale wrt. last update time, then the device selected to read the pool-level metadata may possibly contain stale metadata.
Ah, I think I understand. This is related to the fact that we cached the BDA but didn't update it if it was changed, is that correct? And we've since corrected this problem in more recent versions?
No description provided.
The text was updated successfully, but these errors were encountered: