Phillip, before suggesting something I try to think through the issue,
and the same I try with feedback.
But after several attempts to explain that changing metadata and
removing the "failed" status (of allready running parts) in the
superblocks of the conflicting parts that are plugged-in (but not to be
added to the running array) breaks hot-plugging, I sadly still can't
recognize any consideration of the bad effects your approach would have
for many users.
And if I think about it, your metadata updates may not have the overall
effect you may expect. When the modified part is plugged in
during future boots, it can get run degraded again, the metadata
is then back to what it was before, and it can again be used normally.
So the metadata updates just breaks hotplugging and you could not
explain a case where continous unintentional flip-flopping would occur
and updating metadata would help.
> If you want to automatically split the
> disk off into a new array after the desync has been detected,
Correct, that is unrelated to the metadata problem, I commented on it
because setting this up has its pitfalls (like UUID dupes and this bug
requiring --zero-superblock to prevent it from biting) and it would much
facilitate comparing, copying etc. in a hot-plug environment.
> but fixing the bug in mdadm is as simple as having it
> detect the conflicting metadata on the second disk caused by the
> divergence, and fixing said metadata
It's even simpler once you can see that fixing metadata creates more
issues than are actually there and updating metadata would really be
able solve.
Phillip, before suggesting something I try to think through the issue,
and the same I try with feedback.
But after several attempts to explain that changing metadata and
removing the "failed" status (of allready running parts) in the
superblocks of the conflicting parts that are plugged-in (but not to be
added to the running array) breaks hot-plugging, I sadly still can't
recognize any consideration of the bad effects your approach would have
for many users.
And if I think about it, your metadata updates may not have the overall
effect you may expect. When the modified part is plugged in
during future boots, it can get run degraded again, the metadata
is then back to what it was before, and it can again be used normally.
So the metadata updates just breaks hotplugging and you could not
explain a case where continous unintentional flip-flopping would occur
and updating metadata would help.
> If you want to automatically split the
> disk off into a new array after the desync has been detected,
Correct, that is unrelated to the metadata problem, I commented on it
because setting this up has its pitfalls (like UUID dupes and this bug
requiring --zero-superblock to prevent it from biting) and it would much
facilitate comparing, copying etc. in a hot-plug environment.
> but fixing the bug in mdadm is as simple as having it
> detect the conflicting metadata on the second disk caused by the
> divergence, and fixing said metadata
It's even simpler once you can see that fixing metadata creates more
issues than are actually there and updating metadata would really be
able solve.