All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Roman Mamedov <rm@romanrm.ru>
Cc: "Mathias Burén" <mathias.buren@gmail.com>,
	Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Performance question, RAID5
Date: Sat, 29 Jan 2011 18:15:46 -0600	[thread overview]
Message-ID: <4D44ADB2.9090707@hardwarefreak.com> (raw)
In-Reply-To: <20110130045706.4e8d6fa2@natsu>

Roman Mamedov put forth on 1/29/2011 5:57 PM:
> On Sat, 29 Jan 2011 23:44:01 +0000
> Mathias Burén <mathias.buren@gmail.com> wrote:
> 
>> Controller device @ pci0000:00/0000:00:16.0/0000:05:00.0 [sata_mv]
>>   SCSI storage controller: HighPoint Technologies, Inc. RocketRAID
>> 230x 4 Port SATA-II Controller (rev 02)
>>     host6: [Empty]
>>     host7: /dev/sde ATA SAMSUNG HD204UI {SN: S2HGJ1RZ800964 }
>>     host8: /dev/sdf ATA WDC WD20EARS-00M {SN: WD-WCAZA1000331}
>>     host9: /dev/sdg ATA SAMSUNG HD204UI {SN: S2HGJ1RZ800850 }
> 
> Does this controller support PCI-E 2.0? I doubt it.
> Does you Atom mainboard support PCI-E 2.0? I highly doubt it.
> And if PCI-E 1.0/1.1 is used, these last 3 drives are limited to 250 MB/sec.
> in total, which in reality will be closer to 200 MB/sec.
> 
>> It's all SATA 3Gbs. OK, so from what you're saying I should see
>> significantly better results on a better CPU? The HDDs should be able
>> to push 80MB/s (read or write), and that should yield at least 5*80 =
>> 400MB/s (-1 for parity) on easy (sequential?) reads.
> 
> According to the hdparm benchmark, your CPU can not read faster than 640
> MB/sec from _RAM_, and that's just plain easy linear data from a buffer. So it
> is perhaps not promising with regard to whether you will get 400MB/sec reading
> from RAID6 (with all the corresponding overheads) or not.

It's also not promising given that 4 of his 6 drives are WDC-WD20EARS, which
suck harder than a Dirt Devil at 240 volts, and the fact his 6 drives don't
match.  Sure, you say "Non matching drives are what software RAID is for right?"
 Wrong, if you want best performance.

About the only things that might give you a decent boost at this point are some
EXT4 mount options in /etc/fstab:  data=writeback,barrier=0

The first eliminates strict write ordering.  The second disables write barriers,
so the drive's caches don't get flushed by Linux, and instead work as the
firmware intends.  The first of these is safe.  The second may cause some
additional data loss if writes are in flight when the power goes out or the
kernel crashes.  I'd recommend adding both to fstab, reboot and run your tests.
 Post the results here.

If you have a decent UPS and auto shutdown software to down the system when the
battery gets low during an outage, keep these settings if they yield
substantially better performance.

-- 
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-01-30  0:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-29 22:48 Performance question, RAID5 Mathias Burén
2011-01-29 22:53 ` Roman Mamedov
2011-01-29 23:44   ` Mathias Burén
2011-01-29 23:57     ` Roman Mamedov
2011-01-30  0:15       ` Stan Hoeppner [this message]
2011-01-30  0:33         ` Mathias Burén
2011-01-30  0:27       ` Mathias Burén
2011-01-30  1:52     ` Keld Jørn Simonsen
2011-01-30  1:54       ` Mathias Burén
2011-01-30  5:56         ` Keld Jørn Simonsen
2011-01-30 12:12           ` Mathias Burén
2011-01-30 19:44             ` Stan Hoeppner
2011-01-30 19:46               ` Mathias Burén
2011-02-01 11:37             ` John Robinson
2011-02-01 13:53               ` Roberto Spadim
2011-02-01 14:02               ` Mathias Burén
2011-02-01 14:32                 ` Roberto Spadim
2011-01-29 23:26 ` CoolCold
2011-01-30  0:18   ` Mathias Burén
2011-01-30  4:44     ` Roman Mamedov
2011-01-30 12:09       ` Mathias Burén
2011-01-30 12:15         ` Roman Mamedov
2011-01-30 19:41           ` Mathias Burén
2011-01-30 19:54             ` Roman Mamedov
2011-01-30 19:58               ` Mathias Burén
2011-01-30 20:03             ` Stan Hoeppner
2011-01-30 21:43               ` Mathias Burén
2011-01-31  3:39                 ` Stan Hoeppner
2011-01-31  3:54                   ` Roberto Spadim
2011-01-31  8:52                 ` Keld Jørn Simonsen
2011-01-31  9:37                   ` Mathias Burén
2011-01-31 13:11                     ` Keld Jørn Simonsen
2011-01-31 14:43                       ` Roberto Spadim
2011-01-31 18:44                         ` Keld Jørn Simonsen
2011-01-31 20:42                       ` NeilBrown
2011-01-31 21:41                         ` Keld Jørn Simonsen
2011-01-31 21:43                           ` Roberto Spadim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D44ADB2.9090707@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=mathias.buren@gmail.com \
    --cc=rm@romanrm.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.