On 05/11/2010 04:53 PM, Neil Brown wrote:
> Theoretically, when the spares are one behind the active array and we need to
> update them all, we should update the spares first, then the rest. If we
> don't and there is a crash at the wrong time, some spares could be 2 events
> behind the most recent device. However that is a fairly unlikely race to
> lose and the cost is only having a spare device fall out of the array, which
> is quite easy to put back it, that I might not worry to much about it.
>
> So if you haven't seen a patch to fix this in a week or two, please remind me.
They're spares. They don't need to have an in-sync generation count.
Change the semantics so that spares have a 0 generation count and only
when they've been activated does their count get brought into sync with
the rest of the array. The only thing needed to make that work is to
not kick them on assembly because their generation count doesn't match,
but that should be trivial (and sane) to do based on the fact that if
they are a spare, they don't contain data, so the generation count
really is meaningless.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
