David Brownlee writes:
> On Fri, 30 Aug 2002, Greg Oster wrote:
> 
> > Manuel Bouyer writes:
> > > On Thu, Aug 29, 2002 at 08:43:29PM -0600, Greg Oster wrote:
> > > >  [..]
> > > > > 	Would there be any chance it could degrade the performance of
> > > > > 	the system?
> > > >
> > > > I've not done any real benchmarking on exactly that, but it shouldn't b
> e
> > > > any worse than partitioning a disk without the RAID.
> > >
> > > Could't there be an issue with parity rebuild or reconstruction ?
> >
> > Yes, you are correct.  But hopefully that is something that doesn't happen
> > very often :)
> >
> > > raidframe will do this in background, slowing down when there are other
> > > I/O going through the RAID, but will it include I/O not going through the
> > > RAID for its computations ?
> >
> > No.  RAIDframe will not know about any other I/O that might be happening to
> > other partitions on a disk.  This includes I/O to other RAID sets as well..
> .
> 
> 	Would there be any utility in an option to postpone the raidctl -P
> 	until after the fsck has been run on a disk? Somewhat compromises
> 	redundancy in favour of getting the system running faster.

Yes.  As much as it would be nice to have the "raidctl -P"'s done *before* the 
fsck, in practise it is better to delay the "raidctl -P"'s until after the 
system is up to multi-user... (or at least through the fsck and/or 
quota-checks).  Having fscks and quota-checks fighting with RAIDframe for disk
bandwidth is not a good way to quickly bring a system up.

If you're volunteering to write such an option, I say "go for it!" :)

Later...

Greg Oster