linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Hardy <mhardy@h3c.com>
To: Dan Stromberg <strombrg@dcs.nac.uci.edu>
Cc: "Jure Pečar" <pegasus@nerv.eu.org>, linux-raid@vger.kernel.org
Subject: Re: raid5 write performance
Date: Fri, 18 Nov 2005 11:23:47 -0800	[thread overview]
Message-ID: <437E2A43.4090207@h3c.com> (raw)
In-Reply-To: <1132341596.28924.10.camel@seki.nac.uci.edu>


Moreover, and I'm sure Neil will chime in here, isn't the clean/unclean
thing designed to prevent this exact scenario?

The array is marked unclean immediately prior to write, then the write
and parity write happens, then the array is marked clean.

If you crash during the write but before parity is correct, the array is
unclean and you resync (quickly now thanks to intent logging if you have
that on)

The non-parity blocks that were partially written are then the
responsibility of your journalling filesystem, which should make sure
there is no corruption, silent or otherwise.

If I'm misunderstanding that, I'd love to be corrected. I was under the
impression that the "silent corruption" issue was mythical at this point
and if it's not I'd like to know.

-Mike

Dan Stromberg wrote:
> Would it really be that much slower to have a journal of RAID 5 writes?
> 
> On Fri, 2005-11-18 at 15:05 +0100, Jure Pečar wrote:
> 
>>Hi all,
>>
>>Currently zfs is a major news in the storage area. It is very interesting to read various details about it on varios blogs of Sun employees. Among the more interesting I found was this:
>>
>>http://blogs.sun.com/roller/page/bonwick?entry=raid_z
>>
>>The point the guy makes is that it is impossible to atomically both write data and update parity, which leaves a window of crash that would silently leave on-disk data+paritiy in an inconsistent state. Then he mentions that there are software only workarounds for that but that they are very very slow.
>>
>>It's interesting that my expirience with veritas raid5 for example is just that: slow to the point of being unuseable. Now, I'm wondering what kind of magic does linux md raid5 does, since its write performance is quite good? Or, does it actually do something regarding this? :)
>>
>>Niel?
>>
> 
> 
> -
> 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

-
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:[~2005-11-18 19:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-18 14:05 raid5 write performance Jure Pečar
2005-11-18 19:19 ` Dan Stromberg
2005-11-18 19:23   ` Mike Hardy [this message]
2005-11-19  4:40     ` Guy
2005-11-19  4:57       ` Mike Hardy
2005-11-19  5:54         ` Neil Brown
2005-11-19 11:59           ` Farkas Levente
2005-11-20 23:39             ` Neil Brown
2005-11-19 19:52           ` Carlos Carvalho
2005-11-20 19:54             ` Paul Clements
2005-11-19  5:56         ` Guy
2005-11-19 19:30           ` raid5 reliability (was raid5 write performance) Carlos Carvalho
2005-11-20  0:27             ` Guy
  -- strict thread matches above, loose matches on Subject: below --
2006-07-02 14:02 raid5 write performance Raz Ben-Jehuda(caro)
2006-07-02 22:35 ` Neil Brown
2006-08-13 13:19   ` Raz Ben-Jehuda(caro)
2006-08-28  4:32     ` Neil Brown
2007-03-30 21:44       ` Raz Ben-Jehuda(caro)
2007-03-31 21:28         ` Bill Davidsen
2007-03-31 23:03           ` Raz Ben-Jehuda(caro)
2007-04-01  2:16             ` Bill Davidsen
2007-04-01 23:08         ` Dan Williams
2007-04-02 14:13           ` Raz Ben-Jehuda(caro)
     [not found]         ` <17950.50209.580439.607958@notabene.brown>
     [not found]           ` <5d96567b0704161329n5c3ca008p56df00baaa16eacb@mail.gmail.com>
2007-04-19  8:28             ` Raz Ben-Jehuda(caro)
2007-04-19  9:20               ` Neil Brown

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=437E2A43.4090207@h3c.com \
    --to=mhardy@h3c.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=pegasus@nerv.eu.org \
    --cc=strombrg@dcs.nac.uci.edu \
    /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).