On Sat, 19 Oct 2013 22:21:25 +0200 Martin Wilck [off-list ref] wrote:

Hi Neil,

quoted

quoted

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 :-)

(still hoping someone else will put their hand up to maintain md though....)

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.

With native MD is it is fairly simple - that 'one additional complexity' does
make a real difference.

 - Before the array is running, you can add any device.
 - When the array is started, anything older than the newest device is
   discarded (with the understanding that a bitmap broadens the "age"
   of the newest device, so that oldish devices can still be included).
 - If the array is started but readonly, the missing devices of the same age
   as the newest device can be added (I think).
 - After the array is read-write, devices can only be added if there is a
   bitmap, and they must be in the age range of the bitmap.

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

Does this really belong in compare_super()?

Currently compare super is for checking if the device belongs to the array at
all.  The test on the sequence number (event counter) is separate.
getinfo_super should return that in info->events.  Current only super0 and
super1 do that, intel and ddf don't.

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.

If there is a container with one array started and the other not, then you
might want to reread the metadata for one array but not the other.
That could get messing but should be do-able.

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.

Sounds reasonable.

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.

Agreed.  We should  do our best to detect the dangerous cases, but they
shouldn't be likely.

NeilBrown