Re: Improving RAIDframe Parity Handling: The Diff

[Jed Davis <jld%panix.com@localhost>]

Alan Barrett <apb%cequrux.com@localhost> writes:

> On Sun, 01 Nov 2009, Jed Davis wrote:
>> The RAID component label has a certain number of unused fields, which
>> are zeroed on label creation and left unchanged otherwise.  Thus,
>> allocating a bit from one of them to indicate that a parity-map kernel
>> has ever touched the RAID suffices.  For determining what the last
>> kernel to touch the RAID was, I'm storing a copy of the label
>> modification counter (incremented whenever the label is changed to avoid
>> combining inconsistent components) in another of the formerly unused
>> fields; a non-parity-map kernel will leave the old number in place while
>> incrementing the modification counter itself, so they will not match.
>
> It seem to me that the extra counter would be sufficient, and that you
> don't also need the extra status bit.  Essentially, you get the same
> information from (extra copy of modification counter != 0) as you get
> from the status bit.

While it's quite unlikely that the mod counter would ever wrap, I
thought it best to have an explicit indicator; also, there are other
flags in that flag word, so there isn't much gained by removing one of
them.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))