Re: mdadm 3.3 fails to kick out non fresh disk

[Martin Wilck <mwilck@arcor.de>]

Hi Neil,

>> Martin started addressing this in another new thread whose subject is
>> "RFC: incremental container assembly when sequence numbers don't
>> match"
>>
>>
> Ah yes, thanks.  I had a quick look and it seems to make sense, but it
> deserves more thorough consideration.
> I'll get on to that sometime soon.


Good that you're back. I was starting to get nervous :-)

Wrt the sequence number issue: One thing that I need to understand
better is how native MD deals with this kind of thing. Containers have
one additional complexity: one set of meta data for several subarrays.

IMO one thing I think we need is cleaner semantics for compare_super().
The return to distinguish at least the cases

  0 - OK
  1 - fatal incompatibility
  2 - nonfatal, new disk has "older" meta data
  3 - nonfatal, new disk has "newer" meta data

IMSM already has this to some extent.

The logic to handle this must be in the generic, non-metadata-specific
code. Metadata handlers need methods to force re-reading the meta data
from certain disk(s). mdmon also needs a way to detect that it needs to
reread the meta data.

Furthermore,  at least compare_super_ddf does not only compare, it also
makes changes to its internal data structures; I think other meta data
handlers do the same. IMO it would be more appropriate to do this in a
separate call, after the caller has decided if and how to merge the meta
data.

Then we need to make sure that (to the maximum extent possible) these
issued are handled similarly during Assembly and Incremental Assembly.

The "nonfatal" case is similar to the current "homehost" logic.

As for the complex scenarios in my "RFC" mail, thinking more about it, I
found that the dangerous incremental assembly cases are not so critical
after all, as long as subarrays aren't started prematurely, which is
mostly guaranteed by the current udev rules.

Regards
Martin