On Sat, 19 Oct 2013 22:21:25 +0200 Martin Wilck <mwilck@xxxxxxxx> wrote: > 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 :-) (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
Attachment:
signature.asc
Description: PGP signature
