On 12/12/13 18:11, Pieter De Wit wrote:
Hi,
<snip>
When resyncing a RAID5, is the CPU running 100%? Even old CPUs should be
able to resync faster than that. What CPU is that if I may ask?
I just confirmed they are *not* at 100% so the bottleneck is somewhere else. Here is the last cpu in cpuinfo:
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 7
microcode : 0x38
cpu MHz : 2791.161
cache size : 512 KB
physical id : 3
siblings : 1
core id : 0
cpu cores : 0
apicid : 7
initial apicid : 7
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid
xtpr
bogomips : 5582.28
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 32 bits virtual
power management:
This is rebuilding of RAID6:
[>....................] resync = 0.1% (1215876/732443136)
finish=4444.2min speed=2741K/sec
# tail sync_speed sync_speed_max sync_speed_min
==> sync_speed <==
2788
==> sync_speed_max <==
200000 (system)
==> sync_speed_min <==
200000 (local)
# tail sync_speed sync_speed_max sync_speed_min
==> sync_speed <==
2788
==> sync_speed_max <==
200000 (system)
==> sync_speed_min <==
200000 (local)
# dmesg | grep "raid6: using algorithm"
[ 2.244060] raid6: using algorithm mmxx2 (1916 MB/s)
We have similar CPUs here and we get good resync speed. How many disks
are in your array, and what's their size?
Maybe one of your disk is not performing well, you could try to profile
their individual speed.
I, naively perhaps, assumed the bottleneck to be the Intel CPU's
which sparked this idea. What about block level hashing ? (Unless
this is already done and I just never knew it :) )
Like keeping a checksum of each RAID chunk or stripe for data
consistency checks? RAID doesn't deal with that, it deals with
reconstructing data in the event of a drive failure but doesn't
guarantee data consistency. Therefore, if some bits on a drive were to
be "flipped", the next RAID "scrub" (repair) would detect a mismatch
between the data chunks and the parity and would simply update the
parity from the available data (not "repairing" the corrupted data), as
far as I know that's because there's no way for the array to know
whether the data or the parity was written wrong or corrupted.
Regards,
Ben.
Is there parity in RAID10/RAID1 ? It seems my idea won't work either way as there isn't the bus bandwidth to support it, this is now more an educational thing :)
RAID1 is a mirror (a full copy), while RAID10 is different than RAID1
it's still not using parity but chunk copies.
Cheers,
Pieter
--
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
