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
Attachment:
pgpz7C93luB8n.pgp
Description: PGP signature
