Hi,
I'm performing various lvm/raid experiments on my system. As a result,
I've trashed one of the two disks of a raid1 set. So now the raid is
rebuilding, as soon as it finished I intend to retry experimenting
(disconnect one drive in the raid set, experiment with the other, if big
mistake replug the other one and sync with it).
However mdmadm resync is dog slow (if gracefully backgrounded)
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdc1[2] hda1[0]
2096384 blocks [2/1] [U_]
resync=DELAYED
md1 : active raid1 hdc3[2] hda3[0]
76886976 blocks [2/1] [U_]
[=>...................] recovery = 5.6% (4374912/76886976)
finish=1164.8min speed=1036K/sec
Is there a way to speed it up ? I don't want to wait 1164.8min, and I
don't care if the resync monopolises most of the system.
Kernel is 2.6.14-git11 based (from Fedora Core Devel)
The two disks are identical PATA models :
ATA device, with non-removable media
Model Number: Maxtor 6Y080L0
Serial Number:
Firmware Revision: YAR41BW0
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 160086528
device size with M = 1024*1024: 78167 MBytes
device size with M = 1000*1000: 81964 MBytes (81 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 1
Standby timer values: spec'd by Standard, no device specific
minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0000)
Recommended acoustic management value: 192, current value: 128
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5
*udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
SMART feature set
* FLUSH CACHE EXT command
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
SET MAX security extension
Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
on the following controller :
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Giga-byte Technology: Unknown device 5002
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Regards,
--
Nicolas Mailhot
On Fri, 11 Nov 2005, Nicolas Mailhot wrote:
> I'm performing various lvm/raid experiments on my system. As a result,
> I've trashed one of the two disks of a raid1 set. So now the raid is
> rebuilding, as soon as it finished I intend to retry experimenting
> (disconnect one drive in the raid set, experiment with the other, if big
> mistake replug the other one and sync with it).
>
> However mdmadm resync is dog slow (if gracefully backgrounded)
Just echo large numbers into both min and max resync speed proc entries:
/proc/sys/dev/raid/spped_limit_max and speed_limit_min
e.g. as root do:
echo 200000 > /proc/sys/dev/raid/speed_limit_max
echo 200000 > /proc/sys/dev/raid/speed_limit_min
And watch the speed fly up till it maxes out your hardware. (-:
The above will set both speeds to 200MiB/s which ought to be more than
your devices can do...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Nicolas Mailhot <[email protected]> :
[...]
> Is there a way to speed it up ? I don't want to wait 1164.8min, and I
> don't care if the resync monopolises most of the system.
Naïve question: what do the sysctl dev.raid.speed_limit_{min/max} say ?
--
Ueimor
On the original system I have :
# /sbin/sysctl dev.raid.speed_limit_min
dev.raid.speed_limit_min = 1000
# /sbin/sysctl dev.raid.speed_limit_max
dev.raid.speed_limit_max = 200000
After the suggested change the sync starts flying and the system is
still very responsive. Thanks a lot Anton, looks like the default is
much too conservative for my system!
BTW since I'll be doing some pvmoves later on does a similar tunable
exist to speed it up too ? (will move the LVM which is on this raid to
another software raid array)
Regards,
--
Nicolas Mailhot