From: Stan Hoeppner <stan@hardwarefreak.com>
To: Steve Bergman <sbergman27@gmail.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Is this expected RAID10 performance?
Date: Sat, 08 Jun 2013 22:08:14 -0500 [thread overview]
Message-ID: <51B3F19E.3040805@hardwarefreak.com> (raw)
In-Reply-To: <CAO9HMNHVNQcU=FumFnLRd9b0msMr8fr0z6SmL82dksu+6CNXYA@mail.gmail.com>
On 6/8/2013 2:56 PM, Steve Bergman wrote:
> First of all, thank you to the people who took the time to help
> illuminate this issue.
>
> To summarize... for unknown reasons, the 4 port SATA controller on the
> Dell PET-310 has an aggregate limitation of ~1.75 Gbit/s on the A&B
> and C&D port pairs. Each port can provide more than that to a single
> drive, but when trying to read or write both ports simultaneously,
> each port in the pair gets ~0.87Gbit/s. (Which is probably some
> higher nominal value minus some overhead.)
This is almost certainly a result of forced IDE mode. With this you end
up with a master/slave setup between the drives on each controller, and
all of the other overhead of EIDE.
____ _ _ ___ ____
/ ___|| \ | |_ _| _ \
\___ \| \| || || |_) |
___) | |\ || || __/
|____/|_| \_|___|_| running down of XFS, showing desire for O_PONIES.
> Anyway, that's enough for me on this topic. Feel free to discuss among
> yourselves. But the back and forth on this could go on for weeks (if
> not more) and I don't care to allocate the time (delayed or not ;-)
When you drop a bomb like you have here, and run away, it simply tells
everyone that you're not willing to defend your claims and opinions.
Thus all of that typing was a waste of your time as it will be ignored.
Given your misstatements of fact, about both XFS and EXT4, I can see
why you're running away. I won't bother debunking all of it. I will
simply say this.
If you'd learn to properly use fsync or O_DIRECT in your application
you'd have no problem with data/file integrity with XFS, EXT4, or any
filesystem. Either puts the data on the platter right now. You
apparently write all 2GB of your data to buffer cache and then issue a
sync. That is *horrible* practice. This *creates* a window of
opportunity for data loss. And you're complaining about XFS delayed
allocation?
WRT your data security complaints about XFS, note that machines exist
today that move an aggregate 6-10GB/s to/from a single XFS filesystems.
Try that with EXT. Such performance isn't possible if one journals
data as you suggest all filesystems should. If you need high
performance throughput from an application *and* data security you use
parallel O_DIRECT.
--
Stan
next prev parent reply other threads:[~2013-06-09 3:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-08 19:56 Is this expected RAID10 performance? Steve Bergman
2013-06-09 3:08 ` Stan Hoeppner [this message]
2013-06-09 12:09 ` Ric Wheeler
2013-06-09 20:06 ` Steve Bergman
2013-06-09 21:40 ` Ric Wheeler
2013-06-09 23:08 ` Steve Bergman
2013-06-10 8:35 ` Stan Hoeppner
2013-06-10 0:11 ` Joe Landman
2013-06-09 22:05 ` Eric Sandeen
2013-06-09 23:34 ` Steve Bergman
2013-06-10 0:02 ` Eric Sandeen
2013-06-10 2:37 ` Steve Bergman
2013-06-10 10:00 ` Stan Hoeppner
2013-06-10 7:19 ` David Brown
2013-06-10 0:05 ` Joe Landman
-- strict thread matches above, loose matches on Subject: below --
2013-06-09 23:53 Steve Bergman
2013-06-10 9:23 ` Stan Hoeppner
2013-06-06 23:52 Steve Bergman
2013-06-07 3:25 ` Stan Hoeppner
2013-06-07 7:51 ` Roger Heflin
2013-06-07 8:07 ` Alexander Zvyagin
2013-06-07 10:44 ` Steve Bergman
2013-06-07 10:52 ` Roman Mamedov
2013-06-07 11:25 ` Steve Bergman
2013-06-07 13:18 ` Stan Hoeppner
2013-06-07 13:54 ` Steve Bergman
2013-06-07 21:43 ` Bill Davidsen
2013-06-07 23:33 ` Stan Hoeppner
2013-06-07 12:39 ` Stan Hoeppner
2013-06-07 12:59 ` Steve Bergman
2013-06-07 20:51 ` Stan Hoeppner
2013-06-08 18:23 ` keld
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=51B3F19E.3040805@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=linux-raid@vger.kernel.org \
--cc=sbergman27@gmail.com \
/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.