Re: /proc/mdstat bug: 2.6.14.2
On Tue, Nov 29, 2005 at 11:35:18AM -0800, Andrew Burgess wrote: The time and speed display for resync is wrong, the recovery numbers are fine. The resync is actually running at a few MB/sec. md1 : active raid6 sdn1[8](S) sde1[9] sdq1[0] sdu1[6] sdo1[5] sdaa3[4] sdab1[2] sds1[1] 1757815296 blocks level 6, 128k chunk, algorithm 2 [8/6] [UUU_UUU_] [] recovery = 3.6% (10616704/292969216) finish=840.3min speed=5597K/sec md0 : active raid6 sdac2[0] sdz1[4] sdy1[2] sdx1[1] sdw1[3] sdv1[5] sdr2[6] 1875299328 blocks level 6, 128k chunk, algorithm 2 [8/7] [UUU_] [==..] resync = 33.1% (103563392/312549888) finish=1.5min speed=2288625K/sec This is a amd64 x2 but running in single processor mode because of all the timer problems with dual cpus do you have powernow modules loaded on this kernel? they might be tricking your internal clock. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /proc/mdstat bug: 2.6.14.2
Little off this topic, but how did you get the AMD64 x2 to run in single processor mode? I was trying to figure this out months ago. Just boot with maxcpus=1 or make a UP kernel. I have it working now SMP by dumping 2.6.14 and using 2.6.13.4. Nothing but trouble with .14 including hosing half of a 3 TB raid6 array. It ran .13 for a day and then the power failed this morning and I accidently let it boot .14 and it I started getting errors on my 3ware controllers in about an hour. Back to 13... Beware if you have 3ware controllers. I have a 7810, 7812 and 8506 in this machine. They start timing out and dropping disks. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
/proc/mdstat bug: 2.6.14.2
The time and speed display for resync is wrong, the recovery numbers are fine. The resync is actually running at a few MB/sec. md1 : active raid6 sdn1[8](S) sde1[9] sdq1[0] sdu1[6] sdo1[5] sdaa3[4] sdab1[2] sds1[1] 1757815296 blocks level 6, 128k chunk, algorithm 2 [8/6] [UUU_UUU_] [] recovery = 3.6% (10616704/292969216) finish=840.3min speed=5597K/sec md0 : active raid6 sdac2[0] sdz1[4] sdy1[2] sdx1[1] sdw1[3] sdv1[5] sdr2[6] 1875299328 blocks level 6, 128k chunk, algorithm 2 [8/7] [UUU_] [==..] resync = 33.1% (103563392/312549888) finish=1.5min speed=2288625K/sec This is a amd64 x2 but running in single processor mode because of all the timer problems with dual cpus mdadm - v2.1 - 12 September 2005 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /proc/mdstat bug: 2.6.14.2
On Tuesday November 29, [EMAIL PROTECTED] wrote: The time and speed display for resync is wrong, the recovery numbers are fine. The resync is actually running at a few MB/sec. md1 : active raid6 sdn1[8](S) sde1[9] sdq1[0] sdu1[6] sdo1[5] sdaa3[4] sdab1[2] sds1[1] 1757815296 blocks level 6, 128k chunk, algorithm 2 [8/6] [UUU_UUU_] [] recovery = 3.6% (10616704/292969216) finish=840.3min speed=5597K/sec md0 : active raid6 sdac2[0] sdz1[4] sdy1[2] sdx1[1] sdw1[3] sdv1[5] sdr2[6] 1875299328 blocks level 6, 128k chunk, algorithm 2 [8/7] [UUU_] [==..] resync = 33.1% (103563392/312549888) finish=1.5min speed=2288625K/sec This is a amd64 x2 but running in single processor mode because of all the timer problems with dual cpus Weird. Does it always report wrong numbers, or was this a once-off? i.e. if you cat the file 5 times in a row, what sorts of results do you get? Are there any interesting kernel messages during the resync? I'm stumped, so any extra info you might be able to provide will probably be useful. Thanks, NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
