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

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

Cool.  :)

Chris

-- 
----------------------------------------------------- chris@cjones.org
Chris Jones                                           Mad scientist at large