Re: resync duration ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sounds like it could be wrapping around as suggested. Since you are
swapping out all the disks have you thought about stopping the array
and using dd to copy the old disk to the new disk. Then there is no
resync period or degraded array.

Ryan

On Thu, May 14, 2009 at 9:58 AM, Bryan Mesich <bryan.mesich@xxxxxxxx> wrote:
> 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
>
--
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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux