On Thu, May 14, 2009 at 03:06:47PM +0200, Rainer Fuegenstein wrote:

Hi guys,

I'm a but confused about the duration of a raid5 resync:

- occasionally, my server with 4*750 gb sata raid5 crashed (because of
problems with the power supply); after rebooting it took about 10 to 12
hours to resync the raid5 (guess it just re-created some parity
information or however it works internally, but didn't have to copy
any data)

- right now I replaced one 750GB disk with a 1.5TB disk, but now
resyncing (according to /proc/mdstat) it is supposed to take only 160
minutes ?! although it needs top copy data to a blank disk ?

Just a guess...but your problem might be an artifact of a bug
that has been recently fixed.  Neil sent out mail on 2009-05-04
with the fix I'm thinking about.  Here is an excerpt from his
mail:

Subject: [md PATCH 4/7] md: tidy up status_resync to handle
large arrays.

Two problems in status_resync.
1. It still used Kilobytes as the basic block unit, while most
   code now uses sectors uniformly.
2. It doesn't allow for the possibility that max_sectors exceeds
   the range of "unsigned long".

So
 - change "max_blocks" to "max_sectors", and store sector numbers
   in there and in 'resync'
 - Make 'rt' a 'sector_t' so it can temporarily hold the number
   of remaining sectors.
 - use sector_div rather than normal division.
 - change the magic '100' used to preserve precision to '32'.
   + making it a power of 2 makes division easier
   + it doesn't need to be as large as it was chosen when we
   averaged speed over the entire run.  Now we average speed over the
   last 30 seconds or so.

is this normal or should I be worried, especially before I pull out
the next 750GB disk and replace it with the next 1.5TB disk ?

If your sync only takes 160 minutes...then I'd start to poke
around.  If its finishing time is reasonable considering the
array size, then I'd continue with the migration.
 

tnx in advance.

Bryan