Re: Improving RAIDframe Parity Handling: The Diff

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

Matthias Scheler <tron%zhadum.org.uk@localhost> writes:

> On Tue, Oct 20, 2009 at 04:53:59PM -0400, Jed Davis wrote:
>> As far as compatibility with non-parity-map kernels, I spent a fair
>> amount of time on this and it should Do The Right Thing -- the parity
>> map is in addition to the existing global dirty bit which is
>> maintained as before, and if the previous kernel to touch the RAID
>> was not parity-map enabled, a parity-map kernel will detect this and
>> disregard the parity map.
>
> That sounds like a reasonable approach. How does a kernel with
> parity map support detect that there is no parity map present on disk?

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.

> From your patch it looks like it would be feasable to pull this
> up into the "netbsd-5" branch. Can you see any reason why that
> would not be possible?

At one point I thought there was a reason, but looking over the diff I'm
not sure what that might have been.  I think I'll try merging it and see
what happens.

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