On 30/06/2011 23:28, NeilBrown wrote:
On Thu, 30 Jun 2011 16:21:57 +0200 Karsten Römke<k.roemke@xxxxxx> wrote:
Hi Phil
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
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.
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?
If that's the case, then one reason it might not do that with raid6 is
if the code is common with the raid5 to raid6 grow case. Then a
"resync" would leave the raid5 parity untouched, so that the set keeps
some redundancy, whereas a "recovery" would temporarily leave the stripe
unprotected.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
