Brian Buhrow writes:
> 	Hello.  I'm still working on configuring my mammoth
> array of IDE disks as a raid 5 array.  I've now got 15 disks active, with
> one hot spare, and one bootable disk, making a total of 17 IDE disks in one
> box.  And, We've installed short enough cables so that we can do dma to the
> disks now without trouble.  We cannot transfer more than 63 sectors at a
> time , so we're striping with 63 sector stripes.  Using cylider stripes of
> 1008 sectors doesn't seem to work, it seems to overload the PCI bus.

You may do better to make 3 RAID 5 sets of 5 disks each, and then 
pull those together into a RAID 0 set.  You end up with more redundancy, and 
will likely end up with better performance too...

> 	However, I'm writing about a much more mundane problem.  
> It looks like /etc/rc.d/raidframe starts up the raid arrays on a system if
> their configuration files are in /etc/raid0-3.conf.  Then, it runs the
> parity checker on each of the configured arrays and stuffs that check in
> background.  My question is, isn't this behavior wrong, since, you don't
> want to run fsck on  an raid array whose parity is unclean? 

There was a (long?) thread ("Re: Why my life is sucking. Part 2.")
in current-users around the middle of January that talked in part about 
this.... if your data is very valuable, and you can afford to wait the time to 
do the re-write, then you probably do want to wait... most of us, however, are 
too impatient (and/or don't care about the data *that* much, given the chances 
of there being a problem..)

> And, wouldn't
> you want to wait for the parity check to complete before beginning normal
> operation  on the array itself?  Doesn't putting this process in background
> cause fsck and mount to proceed before the parity calculation, if it's
> necessary, is done?

Yes.

> If I'm wrong could someone tell me and why?  I'll then leave the
> backgrounding there.

You are right.. but it's a question of risk and time... the odds of something 
'going wrong' before the parity is updated is likely quite small... and since
your users probably want to get working right away (as opposed to waiting 4 
hours (or whatever) for the parity to rebuild), you're probably willing to 
take that risk in order to get people working as quickly as possible..

Later...

Greg Oster