linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 ...

  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).