# Improve Hardisk performances

## enrico3791

I installed Gentoo on old Acer Travelmate 4500 fitted with HD Hitachi HTS424040M9AT00 (40Mb, 4200 rpm, 2Mb buffer).

I'm not happy about HD performances, copy of big file such us cd-rom image can take 10-15 minutes. HD is formated with reiserfs, /boot and /home are having a dedicated partition out of /.

lspci -k returns

```
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)

   Subsystem: Acer Incorporated [ALI] Device 0064

   Kernel driver in use: PIIX_IDE
```

Is there anything at Kernel level that I can activate to get more speed?

Thanks for any suggestions

----------

## eccerr0r

Those 4200 RPM laptop disks are indeed slow.

Some things you should check - is your disk using DMA?

PIIX_IDE is the traditional EIDE driver, so your hd is showing up as /dev/hda ?

What's the results of hdparm -ivtT /dev/hda ?

What you want to see is if DMA is enabled.  Also take a look at the benchmark.

You might want to switch over to libata (the ata_piix driver)  if you can...

----------

## NeddySeagoon

enrico3791,

If you are not using libata you need to migrate very soon as udev no longer make /dev/hd nodes.

libata turns on DMA for you, in fact, you can't turn DMA off.

What do you mean by  *Quote:*   

> ... copy of big file such us cd-rom image ...

 from where to where ?

Copying around the drive is slow because of all the head movements - while the head is being moved, data cannot be read or written but the movements are needed to move the data.

Burning a CD (copying from the HDD to CDROM) can be limited by the CDROM speed. Likewise CDROM to HDD in making an image file.

----------

## enrico3791

Hereafter the result of hdparm on hda

```
/dev/hda:

 multcount     = 16 (on)

 IO_support    =  0 (default) 

 unmaskirq     =  0 (off)

 using_dma     =  1 (on)

 keepsettings  =  0 (off)

 readonly      =  0 (off)

 readahead     = 256 (on)

 geometry      = 16383/255/63, sectors = 78140160, start = 0

 Model=HTS424040M9AT00, FwRev=MA2OA71A, SerialNo=MPA241Q2C8U08A

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=DualPortCache, BuffSize=1739kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160

 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4 

 DMA modes:  mdma0 mdma1 mdma2 

 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 

 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:  ATA/ATAPI-2,3,4,5,6

 * signifies the current active mode

 Timing cached reads:   1458 MB in  2.00 seconds = 730.32 MB/sec

 Timing buffered disk reads:   82 MB in  3.02 seconds =  27.14 MB/sec
```

and DMA is activated.

Concerning big file I mean the following: download an ISO and can't keep the maximum speed (>500kB/s) because the HD is saturated by writing the data already received.

Kernel is currently settled as:

```
Device Drivers -->

   <*> ATA/ATAPI/MFM/RLL support (DEPRECTED) -->

   <M> Serial ATA and Parallel ATA drivers -->
```

but if I do the opposite

```
Device Drivers -->

  < > ATA/ATAPI/MFM/RLL support (DEPRECTED) -->

  <*> Serial ATA and Parallel ATA drivers -->

      <*>Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support
```

when I reboot sytem fails to find partitions. I see in the error message that is looking for sda instead of hda. Shall I have to change fstab from hda to sda?

----------

## eccerr0r

looks like DMA is enabled and you're getting about as fast as you're going to get burstwise from the disk, how full is the disk, is it heavily fragmented?  Did you download the image via some bit torrent client like rtorrent, which is notorious for fragmenting files on ext3fs?

as to the sda question, yes you need to switch to /dev/sda* instead of /dev/hda, it's part of the libata transition...

(and I need to somehow do the same for my raid5 box...so far my libata kernels don't autodetect my raid anymore...)

----------

## jathlon

 *enrico3791 wrote:*   

> Hereafter the result of hdparm on hda
> 
> ```
> /dev/hda:
> 
> ...

 

It seems like it's been forever since I had an pata drive.  But if my memory serves me correctly the 'hot' tip of the day was to turn on multicount (which you do have turned on.  Looks like it may be the standard argument in /etc/conf.d/hdparm for pata drives) turn on IO_support and set it to 32bit [ -c2 ] and unmasqirq [ -u1 ]

I'm not really sure that those options for hdparm are available under libata for pata drives, but I have noticed that libata tends to do some of those things automatically and you don't need to worry about them.   Things like IO_support is automatically set to 32-bit with with sata under libata.  Though I do notice that multicount is off for my harddrives while it is on for my ssd.  (Got a warning that -m was dangerous when I queried the drives.  Seems to work well enough as they are.)

I also can't remember if those options made much of a difference..  Heheh.  Might have been one of those micro-optimizations that I was prone too.

You never mentioned what mount options you are using and that can also make some difference to apparent drive speed.  How are you mounting the partitions?

joe

----------

## eccerr0r

I've found that multiple sector transfer count (multcount) and 32-bit transfers don't make much of a difference, at least I didn't notice much of one.

IRQ unmasking shouldn't make much of a difference, it's to reduce latency for other applications (particularly other interrupt handlers), not disk...

I'd still look into fragmentation, try filefrag filename.iso (as root) to see how many fragments you're dealing with.

----------

## enrico3791

I made filefrag on 640 Mb file. The result is 53821.

How can I defrag a reierfs partition?

----------

## eccerr0r

that's a lot of fragments, about 10KB per fragment - which means the head seeks every 10KB adding a few milliseconds per fragment - adding a large amount of time to read the file.  This is kind of expected when downloading with many bittorrent clients.

Many filesystems simply don't have a defragmentation program.  What I do is just copy the file to an empty disk or empty portion of the disk, delete the old file (IMPORTANT, must DELETE the old file to reclaim its space), and copy it back.  This tends (but not always) defragments the file somewhat as now the filesystem can appropriately find extents large enough to hold larger portions of the file.

----------

