Subject: Re: 3ware RAID controller slow?
To: None <netbsd-users@NetBSD.org>
From: Douglas A. Tutty <dtutty@porchlight.ca>
List: netbsd-users
Date: 10/28/2007 18:16:37
On Mon, Oct 29, 2007 at 12:04:47AM +0200, Jukka Marin wrote:
> On Sun, Oct 28, 2007 at 10:55:53PM +0100, Michael van Elst wrote:
> > On Sun, Oct 28, 2007 at 10:50:31PM +0200, Jukka Marin wrote:
> > 
> > > No swap is in use, if that's what you mean.  But no, 4 GB of RAM is not
> > > enough to buffer 10 GB files.. :)
> > 
> > I guess this is the problem. When you run out of buffers then the
> > VM system and thus the file cache gets very slow.
> 
> Then why is RAID5 slow and a plain disk isn't (when extracting the same
> pkgsrc tarball)?  I'm trying to find out whether I can use RAID5 or not,
> that's why I'm asking ;)

Some thoughts:

RAID5 means computing parity.  On a hardware RAID card, the hardware is
supposed to do it; on software RAID, the software does it.  Either way,
parity must be computed and written to multiple disks.  Since you're
extracting a tarball:

plain disk:

	grab a block from the tarball
	unpack the block
	write the block to the filesystem
		write block to disk

raid5:
	grab a block from the tarball
		pull correct data and parity blocks from disks
		calculate parity ensure correct
	unpack the block
	write the block to the filesystem
		calculate the parity of the block
			write data and parity blocks to disks.

plain disk does one read and one write for each block
	(assuming that swap isn't being hit)

raid5 does two reads and two writes for each block
	plus two parity calcs.

	If its hardware, the disk writes and reads should be in parallel
	Is the parity calc done fast enough to keep the drives served or
	does it become a bottleneck?  If its software raid, does it eat
	into the tarball unpack time?

I've seen on the Debian-user list some references to a document on the
net about why not to use raid5 but rather raid 1 or 10.  Performance is
the big issue.

Doug.