[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improving RAIDframe Parity Handling: The Diff
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
(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)))))
Main Index |
Thread Index |