is Raid 1 (mirror) so slow ?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

is Raid 1 (mirror) so slow ?

Arie Reynaldi Z
I'd like to get more stability and fast recovery for my server. So i
decide to make RAID 1 (mirror) using 2 SATA hd, since using raid 1 i
almost dont have to worry about hardisk failure.
 I want to use RAID 5 using 3 HD but this will cost me more. The
server will running java using tomcat, and mysql db. But our vendor
said that using RAID 1 is slower then using 1 HD. Is this true ? If i
use as application server using database, would be enough ? Another
thing, I use softraid from yast.

--
Arie Reynaldi Zanahar
reymanx at gmail.com
http://www.reynaldi.or.id

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Fajar Priyanto
On Thursday 09 November 2006 09:58, Arie Reynaldi Z wrote:
> I'd like to get more stability and fast recovery for my server. So i
> decide to make RAID 1 (mirror) using 2 SATA hd, since using raid 1 i
> almost dont have to worry about hardisk failure.
>  I want to use RAID 5 using 3 HD but this will cost me more. The
> server will running java using tomcat, and mysql db. But our vendor
> said that using RAID 1 is slower then using 1 HD. Is this true ? If i
> use as application server using database, would be enough ? Another
> thing, I use softraid from yast.

Software RAID level 1 is slower than 1 harddisk? Not true. Writing and Reading
speed is good. But, it's the most expensive solution in terms of money per
MB.
Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
performance is a bit slower since it must calculate the parity. Reading speed
is good.

I use software RAID 1 on my mailserver with 2x150GB sata Seagate. So far it's
satisfactory.
HTH,
--
Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial
http://linux2.arinet.org
11:58am up 3:53, 2.6.16.13-4-default GNU/Linux
Let's use OpenOffice. http://www.openoffice.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Joachim Schrod
In reply to this post by Arie Reynaldi Z
Arie Reynaldi Z wrote:
> I'd like to get more stability and fast recovery for my server. So i
> decide to make RAID 1 (mirror) using 2 SATA hd, since using raid 1 i
> almost dont have to worry about hardisk failure.
> I want to use RAID 5 using 3 HD but this will cost me more. The
> server will running java using tomcat, and mysql db. But our vendor
> said that using RAID 1 is slower then using 1 HD. Is this true ? If i
> use as application server using database, would be enough ? Another
> thing, I use softraid from yast.

RAID 1 is actually faster when reading, because read requests can be
satisfied from both disks.

It is a bit slower when writing, but only a few %.

The real-world performance also depends on your file system and on
your RAM and the resulting filesystem cache. (Many I/O requests can
be delivered from the cache.) On my mirrored SATA disks with ext3, I
get about 30 MB/s when I really write to the disks. To get faster
I/O, I would need to use striping massively. (Always remember to
stripe the mirrored disks, and not the other way round.)

But you can do some tests for yourself, if you can set up a test
system with mirroring: install bonnie++ and check the performance
before and after mirroring.

All in all, all our disks are mirrored (softraid 1). With current
disk prices, that's easy to do.

Best,
        Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: [hidden email]
Roedermark, Germany

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Arie Reynaldi Z
In reply to this post by Fajar Priyanto
> Software RAID level 1 is slower than 1 harddisk? Not true. Writing and Reading
> speed is good. But, it's the most expensive solution in terms of money per
> MB.
> Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
> performance is a bit slower since it must calculate the parity. Reading speed
> is good.

I googled and found this:
http://www.catux.org/index.php?contingut=articles&num=101

It shows that using software RAID 1 is slower then others.. Can
someone explain about this ? It used Bonnie++ just like Joachim said.

regards,


--
Arie Reynaldi Zanahar
reymanx at gmail.com
http://www.reynaldi.or.id

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Ken Jennings
On Thursday 09 November 2006 05:22, Arie Reynaldi Z wrote:

> > Software RAID level 1 is slower than 1 harddisk? Not true. Writing and
> > Reading speed is good. But, it's the most expensive solution in terms of
> > money per MB.
> > Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
> > performance is a bit slower since it must calculate the parity. Reading
> > speed is good.
>
> I googled and found this:
> http://www.catux.org/index.php?contingut=articles&num=101
>
> It shows that using software RAID 1 is slower then others.. Can
> someone explain about this ? It used Bonnie++ just like Joachim said.

A mirror uses two drives.  Data has to be written to both drives.  File
systems/buffers help hide this to some extent, but in the end twice as much
work must be done, so it is reasonable to expect it to be slower for writes.

But, as the charts on that web page show, the mirror is not twice as slow.  
So, a software Raid mirror is a good compromise for reliability and
performance without spending big money on enterprise class hardware raid.

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Carlos E. R.-2
In reply to this post by Fajar Priyanto
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Thursday 2006-11-09 at 12:01 +0700, Fajar Priyanto wrote:

> Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
> performance is a bit slower since it must calculate the parity. Reading speed
> is good.

But write operations are distributed over the three disks and
parallelized, so it should be faster.

- --
Cheers,
       Carlos E. R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFUydatTMYHG2NR9URAnRDAKCFaROwLTY9CBJPvlVw7v6g/130GQCeMG/e
Oo1A4NcIQ+Zvqc3SRC4PBnU=
=Q4Dc
-----END PGP SIGNATURE-----


--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

S Glasoe
On Thursday November 9 2006 7:04 am, Carlos E. R. wrote:
> The Thursday 2006-11-09 at 12:01 +0700, Fajar Priyanto wrote:
> > Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
> > performance is a bit slower since it must calculate the parity. Reading
> > speed is good.
>
> But write operations are distributed over the three disks and
> parallelized, so it should be faster.
>
>        Carlos E. R.

Not. RAID5 has to first write the data, then it has to calculate the parity,
then it writes the parity. It can't do all three in parallel. It has to
actually write the data portion so  it has the necessary information to
calculate the parity and then write the parity.

RAID5 write performance sucks. RAID5 read performance can be faster than a
single hard drive due to more data actually being in cache somewhere and
not having to do a physical I/O to a drive.

Stan

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

S Glasoe
In reply to this post by Arie Reynaldi Z
On Thursday November 9 2006 4:22 am, Arie Reynaldi Z wrote:

> > Software RAID level 1 is slower than 1 harddisk? Not true. Writing and
> > Reading speed is good. But, it's the most expensive solution in terms
> > of money per MB.
> > Software RAID level 5 is slower than 1 harddisk? Partly true. Writing
> > performance is a bit slower since it must calculate the parity. Reading
> > speed is good.
>
> I googled and found this:
> http://www.catux.org/index.php?contingut=articles&num=101
>
> It shows that using software RAID 1 is slower then others.. Can
> someone explain about this ? It used Bonnie++ just like Joachim said.
>
> regards,
> Arie Reynaldi Zanahar

As usual with benchmarks its what they don't document that really matters.
That attempt at documenting RAID performance is lacking in details that
really matter to the performance reported. In one chart it shows RAID1 as
taking twice as long to complete as a single drive. Tells me that its
probably IDE and both drives are on the same channel/bus; /dev/hda
and /dev/hdb.

There isn't any mention of how these drives are configured either in
hardware or software. Are they on the same bus on the same controller? Are
they spread across multiple busses and multiple controllers? Are these
drives the same manufacturer, model number and firmware version? How are
the drives partitioned and are they all the same? Is the system /swap on
any of the drives in the test? If the system drive with /swap and / is on a
separate drive is that drive on a channel/bus that the test drives are on?

If the RAID1 drives are on the same IDE channel then only 1 I/O operation
happens at a time and is a bottleneck. Since RAID5 needs a minimum 3 drives
then at least 1 drive will be on a different bus and 2 I/Os can happen
almost at once but 2 drives will be on the same bus and only 1 I/O will
happen at a time there. Known bottleneck that doubles the time you think an
I/O should take to complete.

With basic IDE make sure you do something like /dev/hda RAID1 to /dev/hdc.
Don't even put a CD/DVD drive on either /dev/hdb or /dev/hdd. Get more IDE
controllers for more devices.

So, what hardware do you have to work with, what will the system be used
for, is data protection more important than performance?

Stan

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Carlos E. R.-2
In reply to this post by S Glasoe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Thursday 2006-11-09 at 08:30 -0600, Stan Glasoe wrote:

> Not. RAID5 has to first write the data, then it has to calculate the parity,
> then it writes the parity. It can't do all three in parallel. It has to
> actually write the data portion so  it has the necessary information to
> calculate the parity and then write the parity.

I don't think that is correct.

So says the HOWTO:

     Both read and write performance usually increase, but can be hard
     to predict how much. Reads are similar to RAID-0 reads, writes can
     be either rather expensive (requiring read-in prior to write, in
     order to be able to calculate the correct parity information), or
     similar to RAID-1 writes. The write efficiency depends heavily on
     the amount of memory in the machine, and the usage pattern of the
     array. Heavily scattered writes are bound to be more expensive.



- --
Cheers,
       Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFU07TtTMYHG2NR9URAkgQAJ0aHAfY7FMG9O/vlKyXc8dxMPGwtACdG0/+
tq/yMD1vN4V+YHlZ7wE9cIA=
=Iflu
-----END PGP SIGNATURE-----


--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

S Glasoe
On Thursday November 9 2006 9:52 am, Carlos E. R. wrote:

> The Thursday 2006-11-09 at 08:30 -0600, Stan Glasoe wrote:
> > Not. RAID5 has to first write the data, then it has to calculate the
> > parity, then it writes the parity. It can't do all three in parallel.
> > It has to actually write the data portion so  it has the necessary
> > information to calculate the parity and then write the parity.
>
> I don't think that is correct.
>
> So says the HOWTO:
>
>      Both read and write performance usually increase, but can be hard
>      to predict how much. Reads are similar to RAID-0 reads, writes can
>      be either rather expensive (requiring read-in prior to write, in
>      order to be able to calculate the correct parity information), or
>      similar to RAID-1 writes. The write efficiency depends heavily on
>      the amount of memory in the machine, and the usage pattern of the
>      array. Heavily scattered writes are bound to be more expensive.
>
>        Carlos E. R.

The How To in this case gives incomplete information. If there is a write at
all on RAID5 then it isn't similar to RAID1. All the calculations may be
done in system or controller card memory but as far as benchmark software
timing is concerned RAID5 still has to make 2 writes versus RAID1 making 1
write before that I/O is considered done.

RAID1 can write to one disk and then when time and work load permits, mirror
that write to the other drive. Both drives typically aren't written to at
the same time. So once the data is committed to either disk the benchmark
doesn't track the other I/O but may be affected since that background I/O
may delay a read or write that is next in queue. That background write
probably doesn't interfere with the next I/O since if that drive is busy
then the other drive most likely isn't and the next I/O the benchmark is
counting goes to the available drive; not always but often enough.

RAID5 writes have to calculate and write the changed parity. That adds I/O
delay and it is always more than RAID1. A RAID5 write has to write a data
chunk, read the other data chunk, calculate parity and then write the
parity chunk. Now the I/O is committed to disk and the benchmark can call
it complete. 2 writes are involved; changed data and changed parity.

Hence my opinion that RAID5 writes always suck in the performance area. They
do, they can't help it. Depending on the system, is that performance hit of
any concern versus the survivability of the data?

Stan

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

gregfreemyer
On 11/9/06, Stan Glasoe <[hidden email]> wrote:

> On Thursday November 9 2006 9:52 am, Carlos E. R. wrote:
> > The Thursday 2006-11-09 at 08:30 -0600, Stan Glasoe wrote:
> > > Not. RAID5 has to first write the data, then it has to calculate the
> > > parity, then it writes the parity. It can't do all three in parallel.
> > > It has to actually write the data portion so  it has the necessary
> > > information to calculate the parity and then write the parity.
> >
> > I don't think that is correct.
> >
> > So says the HOWTO:
> >
> >      Both read and write performance usually increase, but can be hard
> >      to predict how much. Reads are similar to RAID-0 reads, writes can
> >      be either rather expensive (requiring read-in prior to write, in
> >      order to be able to calculate the correct parity information), or
> >      similar to RAID-1 writes. The write efficiency depends heavily on
> >      the amount of memory in the machine, and the usage pattern of the
> >      array. Heavily scattered writes are bound to be more expensive.
> >
> >        Carlos E. R.
>
> The How To in this case gives incomplete information. If there is a write at
> all on RAID5 then it isn't similar to RAID1. All the calculations may be
> done in system or controller card memory but as far as benchmark software
> timing is concerned RAID5 still has to make 2 writes versus RAID1 making 1
> write before that I/O is considered done.
>
> RAID1 can write to one disk and then when time and work load permits, mirror
> that write to the other drive. Both drives typically aren't written to at
> the same time. So once the data is committed to either disk the benchmark
> doesn't track the other I/O but may be affected since that background I/O
> may delay a read or write that is next in queue. That background write
> probably doesn't interfere with the next I/O since if that drive is busy
> then the other drive most likely isn't and the next I/O the benchmark is
> counting goes to the available drive; not always but often enough.
>
> RAID5 writes have to calculate and write the changed parity. That adds I/O
> delay and it is always more than RAID1. A RAID5 write has to write a data
> chunk, read the other data chunk, calculate parity and then write the
> parity chunk. Now the I/O is committed to disk and the benchmark can call
> it complete. 2 writes are involved; changed data and changed parity.
>
> Hence my opinion that RAID5 writes always suck in the performance area. They
> do, they can't help it. Depending on the system, is that performance hit of
> any concern versus the survivability of the data?
>
> Stan

The calculation is not normally done that way.  To compare different
RAID efficiencies the standard process is to calculate or compare the
number of logical writes/second the array will sustain under heavy
load and a well utilized cache to minimize wasted work.

I don't know the details of how linux implements it but conceptually
for the worse case with raid 5 (ie. scattered writes) to update a
single block you have to:

Read original block (even if your updating it 100%)
Read Parity Block
Back-out the original block from the parity calculation  (Simple XOR logic)
Put the new blocks data into the parity calculation (Simple XOR logic)
Write the new data block
Write the new parity block

So it takes 4 i/o's to do a single logical write assuming scattered disk writes.

The good news is you get to spread those i/o across all your disks.  A
Raid 5 made of 4 truly independent disks (ie. no master/slave IDE
conflicts, etc.) can do 4 i/o's simultaneously.

So a busy 4-disk Raid5 can handle the same number of logical writes
per second as a single disk.  On the read side it would be 4 times
faster.  (A 3-disk raid set can only handle 3/4 as many logical writes
per second, but 3x as many reads/second.)

For the best case with RAID-5 (full stripe updates) the OS should
determine that the entire stripe set is being updated so it does not
care about any of the prior data and is able to skip the reads and
only has to write the parity block once.

So for a 4-disk raid5 set it takes 4 i/o's to handle 3 logical block
writes. Since all 4 of those i/o's could happen simultaneously a
4-disk Raid 5 can handle 3x the logical writes/second that a single
disk could.

FYI: RAID 10 should be even better/faster.  Primarily because you
would need 6 disks to hold the capacity of data as a 4-disk Raid5.
And with the extra disks you can do more physical i/o's per second.

Again, all of the above assumes your disk activity is trully
independent.  You don't typically get that with IDE bus based drives.
SCSI is typically independent and I don't know about the SATA
controllers. I haven't seen any simultaneous disk activity benchmarks
yet for them.

Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Thursday 2006-11-09 at 15:54 -0500, Greg Freemyer wrote:

...

> I don't know the details of how linux implements it but conceptually
> for the worse case with raid 5 (ie. scattered writes) to update a
> single block you have to:
>
> Read original block (even if your updating it 100%)
> Read Parity Block
> Back-out the original block from the parity calculation  (Simple XOR logic)
> Put the new blocks data into the parity calculation (Simple XOR logic)
> Write the new data block
> Write the new parity block
>
> So it takes 4 i/o's to do a single logical write assuming scattered disk
> writes.

Question.

The data block, is it written to one disk, or is it split over two disks?

- --
Cheers,
       Carlos E. R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFU7jDtTMYHG2NR9URAu7VAJ9aS9viuUdUFgrAJShtw5PqL8wJ9gCgiEMv
ocUV0QEHvUS6MZd8H7w50vg=
=gFwg
-----END PGP SIGNATURE-----


--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

gregfreemyer
On 11/9/06, Carlos E. R. <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> The Thursday 2006-11-09 at 15:54 -0500, Greg Freemyer wrote:
>
> ...
>
> > I don't know the details of how linux implements it but conceptually
> > for the worse case with raid 5 (ie. scattered writes) to update a
> > single block you have to:
> >
> > Read original block (even if your updating it 100%)
> > Read Parity Block
> > Back-out the original block from the parity calculation  (Simple XOR logic)
> > Put the new blocks data into the parity calculation (Simple XOR logic)
> > Write the new data block
> > Write the new parity block
> >
> > So it takes 4 i/o's to do a single logical write assuming scattered disk
> > writes.
>
> Question.
>
> The data block, is it written to one disk, or is it split over two disks?
>
Again I don't know how Linux does it, but I just did some detail
reconstruction work on a 3-disk hardware raid5 using a dell perc
controller.

IIRC, the blocks were laid out like:

1 2 p
3 p 4
p 5 6
7 8 p

Each block was 64K (ie. 128 sectors), and full stripe was 2x64K or 128K.

So block 1 is on the first disk in the array.  block 2 is on the
second disk in the array, and the first parity block is on the third
disk in the array.  Block 3 is back on the first disk, and so on and
so on.

Now if only a 4K page is being updated, I don't know if just a single
4K page is read from the data block and parity blocks and then updates
done.  Or if the logic only works with full 64K blocks at a time.

FYI, I was working at this low level because the hardware had failed
but I was able to extract fairly good dd images of the drives and I
used a low-cost windows program to rebuild the discrete dd images into
a single logical dd image.  The tool was "Raid Reconstructor" and I
think is was less than $100.

Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

S Glasoe
In reply to this post by Carlos E. R.-2
On Thursday November 9 2006 5:24 pm, Carlos E. R. wrote:

> The Thursday 2006-11-09 at 15:54 -0500, Greg Freemyer wrote:
> > I don't know the details of how linux implements it but conceptually
> > for the worse case with raid 5 (ie. scattered writes) to update a
> > single block you have to:
> >
> > Read original block (even if your updating it 100%)
> > Read Parity Block
> > Back-out the original block from the parity calculation  (Simple XOR
> > logic) Put the new blocks data into the parity calculation (Simple XOR
> > logic) Write the new data block
> > Write the new parity block
> >
> > So it takes 4 i/o's to do a single logical write assuming scattered
> > disk writes.
>
> Question.
>
> The data block, is it written to one disk, or is it split over two disks?
>
>        Carlos E. R.

The data and parity blocks should all be equal sizes. No block should span
physical or logical barriers - in a well written RAID algorithm that is!
This gets into the meat of a RAID implementation because the RAID software
has to know how your controllers and drives are arranged. When initially
formatting a RAID array there should not be any data/parity blocks spanning
a physical device or a logical device. That would cause an I/O per device
for any read or write that accesses that block of spanning data and cause
an unnecessary bottleneck.

Greg is also dead on with the IDE vs SCSI for RAID. SCSI is the way to go
because you can have multiple initiators on each bus/channel. That means
multiple commands can be sent down a SCSI bus and each drive will do what
it has to do independently. IDE causes a dead stop to more than 1 I/O at a
time on a channel.

And we haven't even started down the paths of elevator seeks, ordered
writes, tagged command queuing, etc.

But again it comes down to "What's the budget?", what do we have to work
with here and performance,  protection or both?

Stan

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: is Raid 1 (mirror) so slow ?

Joachim Schrod
In reply to this post by gregfreemyer
Greg Freemyer wrote:

> On 11/9/06, Stan Glasoe <[hidden email]> wrote:
>> On Thursday November 9 2006 9:52 am, Carlos E. R. wrote:
>> > The Thursday 2006-11-09 at 08:30 -0600, Stan Glasoe wrote:
>> > > Not. RAID5 has to first write the data, then it has to calculate the
>> > > parity, then it writes the parity. It can't do all three in parallel.
>> > > It has to actually write the data portion so  it has the necessary
>> > > information to calculate the parity and then write the parity.
>> >
>> > I don't think that is correct.
>> >
>> > So says the HOWTO:
>> >
>> >      Both read and write performance usually increase, but can be hard
>> >      to predict how much. Reads are similar to RAID-0 reads, writes can
>> >      be either rather expensive (requiring read-in prior to write, in
>> >      order to be able to calculate the correct parity information), or
>> >      similar to RAID-1 writes. The write efficiency depends heavily on
>> >      the amount of memory in the machine, and the usage pattern of the
>> >      array. Heavily scattered writes are bound to be more expensive.
>> >
>> >        Carlos E. R.
>>
>> The How To in this case gives incomplete information. If there is a
>> write at
>> all on RAID5 then it isn't similar to RAID1. All the calculations may be
>> done in system or controller card memory but as far as benchmark software
>> timing is concerned RAID5 still has to make 2 writes versus RAID1
>> making 1
>> write before that I/O is considered done.
>>
>> RAID1 can write to one disk and then when time and work load permits,
>> mirror
>> that write to the other drive. Both drives typically aren't written to at
>> the same time. So once the data is committed to either disk the benchmark
>> doesn't track the other I/O but may be affected since that background I/O
>> may delay a read or write that is next in queue. That background write
>> probably doesn't interfere with the next I/O since if that drive is busy
>> then the other drive most likely isn't and the next I/O the benchmark is
>> counting goes to the available drive; not always but often enough.
>>
>> RAID5 writes have to calculate and write the changed parity. That adds
>> I/O
>> delay and it is always more than RAID1. A RAID5 write has to write a data
>> chunk, read the other data chunk, calculate parity and then write the
>> parity chunk. Now the I/O is committed to disk and the benchmark can call
>> it complete. 2 writes are involved; changed data and changed parity.
>>
>> Hence my opinion that RAID5 writes always suck in the performance
>> area. They
>> do, they can't help it. Depending on the system, is that performance
>> hit of
>> any concern versus the survivability of the data?
>>
>> Stan
>
> The calculation is not normally done that way.  To compare different
> RAID efficiencies the standard process is to calculate or compare the
> number of logical writes/second the array will sustain under heavy
> load and a well utilized cache to minimize wasted work.

IMHO, this should not be stated in absolute terms.

E.g., on typical database servers, one uses almost always unbuffered
(synchronous) writes. Only the DBMS caches and the filesystem cache
is turned off. Because there, reliability (the D in ACID) is much
more important than any performance improvement. Cache is a not a
factor in disk benchmarking then, the beef is in fast synchronous
writes when one selects a disk subsystem. The DBMS cache efficiency
will be the same for all RAID variants, the log tablespace
performance limit the overall write efficiency.

This is one of the reasons why one does not use plain IDE or SATA
disks without battery buffers for such systems, but real SCSI disks
where one can control such capabilities in detail. E.g., one
typically selects fs sync flags differently for the temp and the log
tablespaces. (Btw, I prefer EMC storage subsystems for their
reliability and their feature set. This is not a plea for Linux md.)

In real storage selection scenarios, performance benchmarking
depends highly on the application that this server is used on. I do
this for a living, and at the situations where I'm involved
(typically mission-critical servers) RAID-5 is more and more
uninteresting. Current storage prices make RAID-1 practical for
TB-sized storage systems; only at the PB-level we need different
scenarios (HSMs, actually).

        Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: [hidden email]
Roedermark, Germany

--
Check the headers for your unsubscription address
For additional commands send e-mail to [hidden email]
Also check the archives at http://lists.suse.com
Please read the FAQs: [hidden email]