Re: misunderstanding of spare and raid devices? - and one question more

On 01/07/2011 10:50, Robin Hill wrote:

On Fri Jul 01, 2011 at 09:23:43 +0200, David Brown wrote:

quoted

On 30/06/2011 23:28, NeilBrown wrote:

quoted

On Thu, 30 Jun 2011 16:21:57 +0200 Karsten Römke[off-list ref]   wrote:

quoted

Hi Phil

quoted

If your CPU has free cycles, I suggest you run raid6 instead of raid5+spare.

Phil

I started the raid 6 array and get:

Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid6 sde5[4] sdd5[3] sdc5[2] sdb2[1] sda3[0]
         13759296 blocks level 6, 64k chunk, algorithm 2 [5/5] [UUUUU]
         [=================>...]  resync = 87.4% (4013184/4586432) finish=0.4min speed=20180K/sec

                                    ^^^^^^
Note: resync

quoted

when I started the raid 5 array I get

md0 : active raid5 sdd5[4] sde5[5](S) sdc5[2] sdb2[1] sda3[0]
         13759296 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
         [=>...................]  recovery =  6.2% (286656/4586432) finish=0.9min speed=71664K/sec

                                    ^^^^^^^^
Note: recovery.

quoted

so I have to expect a three times less write speed - or is this calculation
to simple ?

You are comparing two different things, neither of which is write speed.
If you want to measure write speed, you should try writing and measure that.

When you create a RAID5 mdadm deliberately triggers recovery rather than
resync as it is likely to be faster.  This is why you see a missed device and
an extra spare.  I don't remember why it doesn't with RAID6.

What's the difference between a "resync" and a "recovery"?  Is it that a
"resync" will read the whole stripe, check if it is valid, and if it is
not it then generates the parity, while a "recovery" will always
generate the parity?

 From the names, recovery would mean that it's reading from N-1 disks,
and recreating data/parity to rebuild the final disk (as when it
recovers from a drive failure), whereas resync will be reading from all
N disks and checking/recreating the parity (as when you're running a
repair on the array).

The main reason I can see for doing a resync on RAID6 rather than a
recovery is if the data reconstruction from the Q parity is far slower
that the construction of the Q parity itself (I've no idea how the
mathematics works out for this).

Well, data reconstruction from Q parity /is/ more demanding than constructing the Q parity in the first place (the mathematics is the part that I know about).  That's why a two-disk degraded raid6 array is significantly slower (or, more accurately, significantly more cpu-intensive) than a one-disk degraded raid6 array.

But that doesn't make a difference here - you are rebuilding one or two disks, so you have to use the data you've got whether you are doing a resync or a recovery.


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