Johan Danielsson writes:
> Greg Oster <oster@cs.usask.ca> writes:
> 
> > Since having incorrect parity isn't the "normal mode of operation",
> > the question becomes "how expensive is the test to see whether or
> > not we need to fix the parity on demand?"  Given all the other stuff
> > that goes on, it actually might not be *that* expensive to do...
> 
> Don't know anything about how rf works, but can't you just keep an
> array of bits, one for each stripe (or whatever the smallest unit is
> called), marking if that stripe is clean or not, and then fix the
> parity if it's not marked clean.

Yup.. something like that could be done... either for each stripe, 
or for some set/region of stripes.  Note that this check would have 
to be done for *every IO* that takes place... If a machine is up 
for quite a few days between outages where the parity needs to be
updated, then the machine is going to be spending a lot of cycles 
checking on this, instead of getting on with doing the IO. 
I'm also trying to remove stuff from that code path, not add to it ;)
All the same, it's obvious that I should think about this one more, 
and/or think more about sectioning the array into 'parity regions' 
(or whatever.)  (The idea here is to allow regions of the array to
be marked 'clean' when they are not in use, such that they wouldn't
need to be touched at all after an unclean shutdown...  It's got 
somewhat similiar goals, but focuses more on trying to eliminate 
unneeded parity rewrites....)

Later...

Greg Oster