From: Joe Landman <joe.landman@gmail.com>
To: Steve Bergman <sbergman27@gmail.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Is this expected RAID10 performance?
Date: Sun, 09 Jun 2013 20:05:35 -0400 [thread overview]
Message-ID: <51B5184F.9040707@gmail.com> (raw)
In-Reply-To: <CAO9HMNHPeXiMmXYtPb29Y2xiOFpznzmP8nBSV09UFCnMrYkEgQ@mail.gmail.com>
On 06/09/2013 04:06 PM, Steve Bergman wrote:
> Google for "ZFS and zeroes" you surely noticed that many of the
s/ZFS/xfs/
[...]
> Saying that "you can lose data with any filesystem" is true... but
> evasive, and misses the point. One could say that speeding down the
Er ... no.
If you insist upon absolute "guarantees" in *any* file system, then
mount it with a sync option, so writes don't return until they are
committed to disk, turn off all write caching on the drive, and turn off
any other write caching throughout the system. And if you believe that
this *guarantees* your data integrity, I'd suggest staying away from
real estate sales people in Florida.
You have to understand what is *guaranteed* and what is not. Where bugs
can hit (yes, bugs in the stack can tank a file system).
You can get corruption *anywhere* along the pathway from CPU to disk.
Anywhere. Even with ECC memory, checksums, etc. Have a good long
gander at this
http://www.snia.org/sites/default/files2/SDC2011/presentations/monday/WilliamMartin_Data_Integerity.pdf
and other articles on T10 DIF.
Understand that file systems do not give you guarantees.
If you must provide a guaranteed non-data lost system, then you need to
engineer a resilient system below the file system itself. At the file
system level, you need to use options which give you the highest
probability of surviving a data loss event. Understand that you *will*
lose data irrespective of what file system you have on there. Its the
best practices that you may or may not choose to implement that matter
here, in terms of how impactful this data loss will be.
If you don't know how to use XFS safely, thats fine. Its a very good
file system, I've personally used it since IRIX days (when I was at
SGI). Many very large organizations swear by it. Few would run without
it. But if you prefer something else, fine. Just understand you are
going to lose data with the other file system as well. Denying that
this is possible is not a viable strategy to ameliorate the damage from
the loss, and fundamentally, your focus should be on risk amelioration
with respect to your choices, not arguing with the development team over
your choices.
Now, please, back to your regularly scheduled IO RAID system ...
next prev parent reply other threads:[~2013-06-10 0:05 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
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 [this message]
-- 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=51B5184F.9040707@gmail.com \
--to=joe.landman@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=rwheeler@redhat.com \
--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 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).