Re: RAID5 performance

From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 12/12/03 

Date: Fri, 12 Dec 2003 20:10:14 GMT

Juha Laiho <Juha.Laiho@iki.fi> wrote:
> "Mike Ruskai" <spamten.knilhtrae@begonedynnaht.net> said:
> >There are six Ultrastar 146Z10 drives, each capable of up to 66MB/sec
> >sustained throughput (near track 0 - goes down to around 40MB/sec towards
> >the last track).
> >
> >With the six drives setup as RAID5 with the default 64KB stripe size, the
> >write performance seems to around 8 to 12MB/sec. That's horribly slow. I
> >know writing parity will slow down writes with RAID5, but it shouldn't
> >slow them down to a fraction of the performance of a single drive.

Eh? Won't it have to read the parity disk, read the target disk, then
write the target disk, then write the parity disk (yesss, I know it's
not a disk but a stripe)?

That would make it four times as slow on write to start with. And
that'sif they do it the way I just suggested. They could read all the
data disks instead of reading the parity disk :-).

> >Read performance is better, about 150MB/sec. However, that's an average

You'd expect it to be equal to the bandwidth available on your buses and
controllers. How are these arranged? Are these scsi or IDE? If IDE, then
you're talking three buses, no? And you can only access one at a time
on each bus. So I'd expect the bandwidth to be three times 60MB/s or
so, which is what you are getting.

> >of only 25MB/sec per drive, which is less than half the transfer rate for
> >the region of the drives that the read testing was done from.

Eh?

> How are you measuring? This might well depend on the write size you're
> using.
>
> So, with small writes (below the stripe size - or was it below
> (ndisks-1)*stripesz), the disk subsystem needs to do read-modify-
> calculate-write cycles to update the parity. When you write big

Yes.

> enough chunks at a time, the read-modify -part becomes obsolete as
> what is being written overwrites all the old data within the stripe,

I don't get that! Surely he's not rewriting the same data area again
and again!

> so as there's no need to read the old data from the stripe to calculate
> the new parity, the RAID controller can just calculate the new parity
> and write the full stripe (incl. new parity).

Eh? He'd have to read the data off all disks to find the current parity
without reading the parity stripe itself. I don't get the argument Are
you saying he can build up a picture in cache of the parity as he
writes? That's not clear to me.

Peter

Relevant Pages

  • RE: Gvinum RAID5 performance
    ... > parity to data ratio, and the less benefit you would get from ... reading every disk in the stripe makes sense. ... random non-conflicting) data can be pulled from different drives, ...
    (freebsd-current)
  • RAID5 on athlon64 machines
    ... looking for a decent RAID5 solution. ... rate is twice the speed of one disk as expected). ... I used a stripe size of 279k ... parity check on reads (a crash may have rendered a stripe ...
    (freebsd-hackers)
  • Re: AIX V5.3 & FASTT500 PERFORMANCE TUNING
    ... calculate the parity data every time a write is done, there is a decrease on performance when compared with reads, which doesn’t require the parity calculation. ... On a RAID_10, there is no parity calculation on either read or write, but there’s almost always a small slowdown in the write performance, due to the disk internals. ... commonly used implementation of RAID, Level 4 provides block-level striping with a parity disk. ... the information contained in this communication ...
    (AIX-L)
  • Re: Solaris 9 vxfs equivalent ?
    ... RAID5 works very similarly to stripe, ... Say your stripe width is K bytes and you have N disks. ... to each disk. ... The new data is written to a data disk, and then the parity disk's ...
    (comp.unix.solaris)
  • Re: Best Raid Level for Streaming?
    ... RAID 3: Striping and Parity ... In RAID level 3, data is striped across a set of disks. ... is generated and stored on a dedicated disk. ... In RAID level 5, both parity and data are striped across a set of disks. ...
    (microsoft.public.windowsmedia.server)