From: Steve Bergman <sbergman27@gmail.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Is this expected RAID10 performance?
Date: Sun, 9 Jun 2013 18:34:13 -0500 [thread overview]
Message-ID: <CAO9HMNGwdLG7ubNP1gC7To9pNstuwZPDAeV03HDkUjh5MWB0Dg@mail.gmail.com> (raw)
In-Reply-To: <loom.20130610T000503-316@post.gmane.org>
Hi Eric,
Yes, I understand what you are saying about the interaction between
ordered data mode and DA in ext4. It's the combination of the 2
options that makes the difference. Merely having a switch to turn off
DA on XFS would not get me what I need for my data volumes. But thank
you for making that explicit.
I intentionally disable DA on my ext4 data volumes specifically to get
ext3-like behavior which results in a night and day difference in
resiliency during... difficult times... for many of my customers, in
my repeated experiences. I could just use ext3. But why give up
extents, multiblock allocation, CRC protection of the journal, etc?
(BTW, that's my vote *not* to remove the nodelalloc option of ext4 as
I noticed you and Ted discussing last April. ;-)
So on a set of Cobol C/ISAM files which never get fsync'd or
fdatasync'd, (because that concept does not exist in Cobol) would you
expect there to be any difference in the resiliency of ext4 and xfs
with both filesystems at completely default settings? Or would it be
about the same. I'm *very* interested in this topic, as I'd like the
best speed and more filesystem options, but need the resiliency even
more for many of my servers. Do I have an option with XFS to improve
behavior on/after an unclean shutdown? If so, I'd sincerely like to
know.
XFS is an excellent filesystem. Indispensable for certain use-cases.
If you need > 16TB files, there's nothing like it. (And I'm sure there
are other good use-cases.) Similarly, DA is a valuable filesystem
feature. And I'm very glad that both XFS & Ext4 have it available to
me. But as with any filesystem or fs feature, there are always
trade-offs, risks and benefits, etc. And those differences have turned
out to be crucially important to me and to quite a number of my
customers.
-Steve
next prev parent reply other threads:[~2013-06-09 23:34 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
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 [this message]
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=CAO9HMNGwdLG7ubNP1gC7To9pNstuwZPDAeV03HDkUjh5MWB0Dg@mail.gmail.com \
--to=sbergman27@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).