2008 R2 Software Raid 5, writing during resynching

Question

I'm build a software Raid 5 under Windows server 2008 R2 with 4 x 2TB SATA2 (i3-540 4GB) I launched the process 24h ago, but the resynch progress is 27% only; - Is there a problem, or is it a normal duration ? Would a 2003R2 raid 5 be faster ? (I've seen that it could take 4 days, but some people told me it shouldn't take more tha 1 day) - Can I write on the raid drive during the resynch process ? Thank you.

Edits :

Actually, I estimate the resynch time to 84 h according to elapsed time and % completed. I don't know if this calculation is correct, but it seem to match my estimated time.

Value are extracted from test of WD Caviar Green 2TO : http://www.ginjfo.com/dossiers/tests-materiel/composants/disques-durs/caviar-green-2-to-une-capacite-ecolo-hors-norme-20090309?page=3 (Access write 3ms, access read 7ms)

• Read and write at max Sata II : 4 * 1.820.000 MB at 375 MB/s (Sata II) = 5.4 H
• Access to each cluster of 3 HDD : 1 * 1.820.000 MB = 28.437.500 64KB clusters at 7ms = 55.3 H (Read simultaneous)
• Write of each parity cluster : 1 * 1.820.000 MB = 28.437.500 64KB clusters at 3ms = 23.7 H (Write parity)

=> 84.4 H (3.5 days)

If the calculation is correct, it could help some people to estimate the resynch time.

Answer 1

That's the problem with using large disks with a RAID: Reconstructing takes ages. It has to read 6 TB worth of data from the other disks, do checksumming etc. and write back 2 TB. In case of a software RAID, it has to do this while normal operation continues.

That said, I would consider ~4 days a bit slow, but doubt that 2003R2 would be any faster on the same hardware.

Reading and writing on the RAID while reconstructing is happening is not a problem except that both normal IO and reconstructing will be a lot slower than usual.

Answer 2

I might also have something to do with you are using a software raid and not a proper hardware raid controller.

Answer 3

Please keep in mind that your calculations are assuming that the system can only read from one drive at a time. Actual read performance per drive should be on the order of 120MB/sec. Concurrently reading 4 drives should yield 480MB/sec, then parity needs to be calculated (concurrent with read because the write is going to the 5th drive) and the parity is written (again, concurrent with read). So the limiting factor should only be parity. Modern processors should be able to easily XOR 480MB/sec of data (heck I can MD5 100MB/sec of data) - meaning that a 5x2TB RAID5 should take no longer than 4.3 Hours if operating at full speed.

In reality my rebuild is looking to take about 96 hours - or operating a 5.5MB/sec total speed per drive. Considering that single-drive reads operate at 120MB/sec that is 1/20th of the maximum read speed.

I believe that the system is doing this as a very low-priority process in order to not overwhelm the rest of the system, but 1/20th seems to be unnecessarily conservative. It should be trivial to throttle the speed of the rebuild based on the overall usage of the system instead of at a low rate fixed speed. But then again nobody ever claimed that built-in windows raid solutions were fast or optimized.

This is also completely ignoring the fact that a brand new raid does not need to synch. No other system that I have used exclusively syncs a new volume without the option for "quick build" with no sync.