All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: stan@hardwarefreak.com, John Williams <jwilliams4200@gmail.com>
Cc: NeilBrown <neilb@suse.de>, James Plank <plank@cs.utk.edu>,
	Ric Wheeler <rwheeler@redhat.com>,
	Andrea Mazzoleni <amadvance@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux RAID Mailing List <linux-raid@vger.kernel.org>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	David Smith <creamyfish@gmail.com>
Subject: Re: Triple parity and beyond
Date: Mon, 25 Nov 2013 10:15:19 +0100	[thread overview]
Message-ID: <52931527.8030002@hesbynett.no> (raw)
In-Reply-To: <52926BE3.1000301@hardwarefreak.com>

On 24/11/13 22:13, Stan Hoeppner wrote:
> On 11/23/2013 11:14 PM, John Williams wrote:
>> On Sat, Nov 23, 2013 at 8:03 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>
>>> Parity array rebuilds are read-modify-write operations.  The main
>>> difference from normal operation RMWs is that the write is always to the
>>> same disk.  As long as the stripe reads and chunk reconstruction outrun
>>> the write throughput then the rebuild speed should be as fast as a
>>> mirror rebuild.  But this doesn't appear to be what people are
>>> experiencing.  Parity rebuilds would seem to take much longer.
>>
>> "This" doesn't appear to be what SOME people, who have reported
>> issues, are experiencing. Their issues must be examined on a case by
>> case basis.
> 
> Given what you state below this may very well be the case.
> 
>> But I, and a number of other people I have talked to or corresponded
>> with, have had mdadm RAID 5 or RAID 6 rebuilds of one drive run at
>> approximately the optimal sequential write speed of the replacement
>> drive. It is not unusual on a reasonably configured system.
> 
> I freely admit I may have drawn an incorrect conclusion about md parity
> rebuild performance based on incomplete data.  I simply don't recall
> anyone stating here in ~3 years that their parity rebuilds were speedy,
> but quite the opposite.  I guess it's possible that each one of those
> cases was due to another factor, such as user load, slow CPU, bus
> bottleneck, wonky disk firmware, backplane issues, etc.
> 

Maybe this is just reporting bias - people are quick to post about
problems such as slow rebuilds, but very seldom send a message saying
everything worked perfectly!

There /are/ reasons why parity raid rebuilds are going to be slower than
mirror rebuilds - delays on one disk reading is one issue, and I expect
that simultaneous use of the array for normal work will have more impact
on parity raid rebuild times than on a mirror array (certainly compared
to raid10 with multiple pairs).  I just don't think it is quite as bad
as you think.


WARNING: multiple messages have this Message-ID (diff)
From: David Brown <david.brown@hesbynett.no>
To: stan@hardwarefreak.com, John Williams <jwilliams4200@gmail.com>
Cc: NeilBrown <neilb@suse.de>, James Plank <plank@cs.utk.edu>,
	Ric Wheeler <rwheeler@redhat.com>,
	Andrea Mazzoleni <amadvance@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux RAID Mailing List <linux-raid@vger.kernel.org>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	David Smith <creamyfish@gmail.com>
Subject: Re: Triple parity and beyond
Date: Mon, 25 Nov 2013 10:15:19 +0100	[thread overview]
Message-ID: <52931527.8030002@hesbynett.no> (raw)
In-Reply-To: <52926BE3.1000301@hardwarefreak.com>

On 24/11/13 22:13, Stan Hoeppner wrote:
> On 11/23/2013 11:14 PM, John Williams wrote:
>> On Sat, Nov 23, 2013 at 8:03 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>
>>> Parity array rebuilds are read-modify-write operations.  The main
>>> difference from normal operation RMWs is that the write is always to the
>>> same disk.  As long as the stripe reads and chunk reconstruction outrun
>>> the write throughput then the rebuild speed should be as fast as a
>>> mirror rebuild.  But this doesn't appear to be what people are
>>> experiencing.  Parity rebuilds would seem to take much longer.
>>
>> "This" doesn't appear to be what SOME people, who have reported
>> issues, are experiencing. Their issues must be examined on a case by
>> case basis.
> 
> Given what you state below this may very well be the case.
> 
>> But I, and a number of other people I have talked to or corresponded
>> with, have had mdadm RAID 5 or RAID 6 rebuilds of one drive run at
>> approximately the optimal sequential write speed of the replacement
>> drive. It is not unusual on a reasonably configured system.
> 
> I freely admit I may have drawn an incorrect conclusion about md parity
> rebuild performance based on incomplete data.  I simply don't recall
> anyone stating here in ~3 years that their parity rebuilds were speedy,
> but quite the opposite.  I guess it's possible that each one of those
> cases was due to another factor, such as user load, slow CPU, bus
> bottleneck, wonky disk firmware, backplane issues, etc.
> 

Maybe this is just reporting bias - people are quick to post about
problems such as slow rebuilds, but very seldom send a message saying
everything worked perfectly!

There /are/ reasons why parity raid rebuilds are going to be slower than
mirror rebuilds - delays on one disk reading is one issue, and I expect
that simultaneous use of the array for normal work will have more impact
on parity raid rebuild times than on a mirror array (certainly compared
to raid10 with multiple pairs).  I just don't think it is quite as bad
as you think.


  parent reply	other threads:[~2013-11-25  9:15 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 22:08 Triple parity and beyond Andrea Mazzoleni
2013-11-18 22:12 ` H. Peter Anvin
2013-11-18 22:35   ` Andrea Mazzoleni
2013-11-18 23:25     ` H. Peter Anvin
2013-11-19 10:16       ` David Brown
2013-11-19 17:36         ` Andrea Mazzoleni
2013-11-19 22:51           ` Drew
2013-11-20  0:54             ` Chris Murphy
2013-11-20  1:23               ` John Williams
2013-11-20 10:35                 ` David Brown
2013-11-20 10:31           ` David Brown
2013-11-20 18:09             ` John Williams
2013-11-20 18:44               ` Andrea Mazzoleni
2013-11-21  6:15                 ` Stan Hoeppner
2013-11-21  8:32               ` David Brown
2013-11-20 18:34             ` Andrea Mazzoleni
2013-11-20 18:43               ` H. Peter Anvin
2013-11-20 18:56                 ` Andrea Mazzoleni
2013-11-20 18:59                   ` H. Peter Anvin
2013-11-20 21:21                     ` Andrea Mazzoleni
2013-11-20 19:00                   ` H. Peter Anvin
2013-11-20 21:04                     ` Andrea Mazzoleni
2013-11-20 21:06                       ` H. Peter Anvin
2013-11-21  8:36               ` David Brown
2013-11-19 17:28       ` Andrea Mazzoleni
2013-11-19 20:29         ` Ric Wheeler
2013-11-20 16:16           ` James Plank
2013-11-20 19:05             ` Andrea Mazzoleni
2013-11-20 19:10               ` H. Peter Anvin
2013-11-20 20:30                 ` James Plank
2013-11-20 21:23                   ` Andrea Mazzoleni
2013-11-27  2:50                     ` ronnie sahlberg
2013-11-20 21:28                   ` H. Peter Anvin
2013-11-21  1:28             ` Stan Hoeppner
2013-11-21  2:46               ` John Williams
2013-11-21  6:52                 ` Stan Hoeppner
2013-11-21  7:05                   ` John Williams
2013-11-21 22:57                     ` Stan Hoeppner
2013-11-21 23:38                       ` John Williams
2013-11-22  9:35                         ` Stan Hoeppner
2013-11-22 11:24                           ` joystick
2013-11-22 15:01                           ` John Williams
2013-11-22 22:28                             ` Stan Hoeppner
2013-11-22 23:07                       ` NeilBrown
2013-11-23  3:46                         ` Stan Hoeppner
2013-11-23  5:04                           ` NeilBrown
2013-11-23  5:34                             ` John Williams
2013-11-23  7:12                               ` NeilBrown
2013-11-24  4:03                                 ` Stan Hoeppner
2013-11-24  4:03                                   ` Stan Hoeppner
2013-11-24  5:14                                   ` John Williams
2013-11-24 21:13                                     ` Stan Hoeppner
2013-11-24 21:13                                       ` Stan Hoeppner
2013-11-24 23:28                                       ` Rudy Zijlstra
2013-11-24 23:28                                         ` Rudy Zijlstra
2013-11-24 23:53                                       ` Alex Elsayed
2013-11-25  2:04                                         ` Stan Hoeppner
2013-11-25  2:04                                           ` Stan Hoeppner
2013-11-25  4:48                                           ` Alex Elsayed
2013-11-25  9:15                                       ` David Brown [this message]
2013-11-25  9:15                                         ` David Brown
2013-11-24  5:19                                   ` Russell Coker
2013-11-24 21:44                                     ` Stan Hoeppner
2013-11-24 22:31                                       ` Mark Knecht
2013-11-25  2:14                                       ` Russell Coker
2013-11-25  9:20                                         ` David Brown
2013-11-21  8:08               ` joystick
2013-11-22  0:30                 ` Stan Hoeppner
2013-11-22  0:33                   ` H. Peter Anvin
2013-11-22  0:45                   ` David Brown
2013-11-21  9:07               ` David Brown
2013-11-21  9:54                 ` Adam Goryachev
2013-11-21 10:32                   ` David Brown
2013-11-22  8:12                   ` Russell Coker
2013-11-25 18:23                     ` Pasi Kärkkäinen
2013-11-22  8:13                 ` Stan Hoeppner
2013-11-22 13:15                   ` David Brown
2013-11-22 16:07                   ` Stan Hoeppner
2013-11-22 22:59                     ` NeilBrown
2013-11-23 17:39                       ` David Brown
2013-11-22 16:50                   ` Mark Knecht
2013-11-22 19:51                     ` Duncan
2013-11-22 19:51                       ` Duncan
2013-11-22  8:38                 ` Stan Hoeppner
2013-11-22 13:24                   ` David Brown
2013-11-28  7:16                     ` Stan Hoeppner
2013-11-28  7:36                       ` Russell Coker
2013-11-28  9:56                       ` David Brown
2013-11-30  7:32                       ` Alex Elsayed
2013-12-01 15:37                         ` Stan Hoeppner
2013-11-22 14:19                   ` David Taylor
2013-11-21 19:56               ` Piergiorgio Sartor
2013-11-19 18:12 ` Piergiorgio Sartor
2013-11-20 10:44   ` David Brown
2013-11-20 21:59     ` Piergiorgio Sartor
2013-11-20 21:59       ` Piergiorgio Sartor
2013-11-21 10:13       ` David Brown
2013-11-21 10:13         ` David Brown
2013-11-21 17:37         ` Goffredo Baroncelli
2013-11-21 17:37           ` Goffredo Baroncelli
2013-11-21 20:05         ` Piergiorgio Sartor
2013-11-21 20:31           ` David Brown
2013-11-21 20:52             ` Piergiorgio Sartor
2013-11-22  0:32               ` David Brown
2013-11-22 20:32                 ` Piergiorgio Sartor
2013-11-26 18:10             ` joystick
2013-11-20 21:38   ` Andrea Mazzoleni
2013-11-20 22:29 ` Piergiorgio Sartor
2013-11-23  7:55   ` Andrea Mazzoleni
2013-11-23 22:10     ` Piergiorgio Sartor
2013-11-24  9:39       ` Andrea Mazzoleni
  -- strict thread matches above, loose matches on Subject: below --
2013-12-01 17:53 Richard Scobie
2013-12-02  4:30 ` Stan Hoeppner

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=52931527.8030002@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=amadvance@gmail.com \
    --cc=creamyfish@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jwilliams4200@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=plank@cs.utk.edu \
    --cc=rwheeler@redhat.com \
    --cc=stan@hardwarefreak.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.