Chris Jones writes:
> Greg Oster <oster@cs.usask.ca> writes:
> 
> > 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. 
> 
> Wouldn't it be better to first check the overall status of the array?

For sure... and if one digs deep enough into RAIDframe, one might even find a 
'no cost' (as opposed to 'low cost') way of doing this... (e.g. w/ function 
pointers and such).

> And once the array's parity has been correctly written, you can free
> the memory used to hold this bitmap.  It means that you're doing two
> checks, not just one, while you're actually doing the on-demand
> re-writing of the parity; but when you're not fixing parity, it ought
> to save you memory, and probably time, too, when you think about
> keeping that whole bitmap in the CPU's cache...
> 
> if(array_is_dirty)
>     if(this_block_is_dirty)
>         rewrite_parity();

Later...

Greg Oster