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.