Subject: Re: Multiple RAID1 partions on same disks
To: David Brownlee <firstname.lastname@example.org>
From: Greg Oster <email@example.com>
Date: 08/30/2002 10:15:21
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
> > > > 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!" :)