Subject: Re: Why my life is sucking. Part 2.
To: Chris Jones <firstname.lastname@example.org>
From: Greg Oster <email@example.com>
Date: 01/18/2001 14:28:06
Chris Jones writes:
> Greg Oster <firstname.lastname@example.org> writes:
> > Johan Danielsson writes:
> > > Greg Oster <email@example.com> 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...