mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
To: linux-kernel@vger.kernel.org
Subject: How to speed up raid1 resync ?
Date: Fri, 11 Nov 2005 15:00:18 +0100	[thread overview]
Message-ID: <1131717619.4133.13.camel@rousalka.dyndns.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

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

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

             reply	other threads:[~2005-11-11 14:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11 14:00 Nicolas Mailhot [this message]
2005-11-11 14:08 ` Anton Altaparmakov
2005-11-11 14:11 ` Francois Romieu
2005-11-11 15:15 ` Nicolas Mailhot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1131717619.4133.13.camel@rousalka.dyndns.org \
    --to=nicolas.mailhot@laposte.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®