# harddisk speed issue

## incubator

I was wondering why it takes about 30 minutes for an updatedb to finish. I have udma enabled on both harddisks.

Although they are quite full, I still dont think it should take this long:

```

/dev/hda:

 Model=MAXTOR 6L020J1, FwRev=A93.0500, SerialNo=661209330172

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

 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4

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

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

 IORDY=on/off, tPIO={min:120,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 udma6 

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 

 * signifies the current active mode

/dev/hdb:

 Model=ST3120023A, FwRev=3.30, SerialNo=3KA0MFWL

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

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

 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=234441648

 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=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 

 * signifies the current active mode

```

----------

## incubator

I would really want to know  if there is sosmething wronog with this setup. Sometimes even Windows reacts faster  :Sad: 

----------

## jokernel

What does 

hdparm /dev/hda

and

hdparm -t /dev/hdaX

say?

Are you using ACPI?

(hda your drive, hdaX your root fs partition)

----------

## incubator

```

# hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 39813/16/63, sectors = 40132503, start = 0

# hdparm -t /dev/hda3

/dev/hda3:

 Timing buffered disk reads:   62 MB in  3.03 seconds =  20.46 MB/sec

```

I am not using ACPI but APM (2.6.0 kernel, in the APM config section, only the first option enabled just to enable APM and the RTC too)

----------

## GentooBox

try this:

```
hdparm -d1 -A1 -m16 -u1 -a64 -X66 /dev/hda
```

and then this:

```
hdparm -tT /dev/hda
```

you should get better performance than the 20,46 Mb/s before.

if your harddisk support higher DMA than -X66, then you should try out -X67, X68 or even X69.

dont set the option higher than your hardware support.

----------

## incubator

thanks, makes a whole difference now  :Smile: 

```

/dev/hda:

 Timing buffer-cache reads:   1028 MB in  2.00 seconds = 513.82 MB/sec

 Timing buffered disk reads:  120 MB in  3.01 seconds =  39.87 MB/sec

```

I set it to X69 though, since as shown above it supports udma5

(if I can trust that info though, sincce I dont have any document of the disk anymore)

----------

## Gatak

And use hdparm -c3 to enable 32bit transfers. You can add all these options into /etc/conf.d/hdparm:

```
all_args="-d1c3u1W1S242"
```

-S242 will enable automatic spin down on your harddisks after 30 minutes (check man page for info on this).

-W1 will enable write chache of your disk. This greatly speeds up things that read and write concurrently (compiling etc). There is a slight risk of data loss IF you loose power while disk is still writing.. This should not be of concern for most people though.

----------

## incubator

hmm, suppose IF this would happen, would a ReiserFS partition still recover and be able to boot?

----------

## Gatak

 *incubator wrote:*   

> hmm, suppose IF this would happen, would a ReiserFS partition still recover and be able to boot?

 Yes. It is not _that_ severe. It would be the same as if the power would go off while the disk would be writing without the cache.

The difference is that the filesystem could need an extra check (which Gentoo/reiserfs tools will do if needed) when you reboot. 

Normally, if a file write operation would not be completed then the journal log in reiserfs will show this (there is not "completed" entry, sort of). But if the harddisk has a internal cache it can tell reiserfs that the data is written while it actually is in the cache. This leads reiserfs to write the "completed" entry to the log and be happy with it.

Risks are very small if you allow the init scripts to check the disk on bootup.

----------

## bookstack

 *jokernel wrote:*   

> What does 
> 
> hdparm /dev/hda
> 
> and
> ...

 

Do you means that ACPI conflicts with the DMA?

I checked my hds' specification, but I could not enable

DMA.

----------

## Gatak

ACPI has nothing to do with the harddisk. However, it can do stuff with the drivers for the IDE controller. If something is wrong there then it might happen that you won't be able to assign a DMA channel or use the proper drivers instead of "generic" ones.

It is very unlikely this is affecting you though.

----------

## mem7

Wow, I didnt realize how bad the setup was for my hard drive. Reading this got me from around 18 megs a sec to 45 megs!

----------

## jokernel

On some systems ACPI C2 and IDE IO does'nt like each other.

If you have a 2.6 kernel try

hdparm -a 4096 /dev/hda

(or 8192) also. It can help a lot.

----------

## incubator

Wow, that really helps a lot  :Very Happy: 

KDE apps start a LOT faster in fluxbox now.

Thanks a lot!  :Smile: 

----------

## Gatak

emerge prelink, then prelink your Gentoo. That will speed up things greatly.

----------

## incubator

how exactly do I prelink my Gentoo? Never done that before

----------

## bookstack

It's so strange that I could not enable the DMA support

for my WD 120 G,

```
HDIO_SETDMA_XX: Operation not permitted.
```

Yes, I do read the Gentree's post.

However, I put the via82cxxx in module, not in the kernel,

and add it to /etc/modules.autoload.d

and 

```
dmesg | grep -i vp_ide
```

do issue something.

Any suggestions ?

----------

## Gatak

I would compile the IDE drivers in the kernel and not use them as modules. This is much safer and should also be somewhat faster (debatable).

I usually compile in support for Generic IDE, Intel, VIA and Promise controllers in case I need to replace the hardware. It works very fine and gives less worries.

For example when I boot using a promise controller I get this output in dmesg:

```
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

PDC20268: IDE controller at PCI slot 0000:00:0a.0

PDC20268: chipset revision 1

PDC20268: ROM enabled at 0xfe000000

PDC20268: 100% native mode on irq 10

    ide0: BM-DMA at 0xfc40-0xfc47, BIOS settings: hda:pio, hdb:pio

    ide1: BM-DMA at 0xfc48-0xfc4f, BIOS settings: hdc:pio, hdd:pio

hda: Maxtor 5T030H3, ATA DISK drive

ide0 at 0xfc78-0xfc7f,0xfc72 on irq 10

hda: max request size: 128KiB

hda: 60030432 sectors (30735 MB) w/2048KiB Cache, CHS=59554/16/63, UDMA(100)

 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3
```

----------

## bookstack

Thanks for your guys' help.  Now, the hdparm benchmark is great !

```

/dev/hda:

 Timing buffer-cache reads:   732 MB in  2.01 seconds = 364.23 MB/sec

 Timing buffered disk reads:  124 MB in  3.03 seconds =  40.86 MB/sec

```

I once select the "Via module" as module, and try to autoload it. Then I got 

the 

```
HDIO_SET_DMA failed: Operation not permitted
```

I then compile the via to the kernel, then everthing is OK.

Here is the result:

```

hdparm -d1 -A1 -m16 -u1 -a64 -X66 /dev/hda

/dev/hda:

 setting fs readahead to 64

 setting multcount to 16

 setting unmaskirq to 1 (on)

 setting using_dma to 1 (on)

 setting xfermode to 66 (UltraDMA mode2)

 setting drive read-lookahead to 1 (on)

 multcount    = 16 (on)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 readahead    = 64 (on)

# hdparm -tT /dev/hda

/dev/hda:

 Timing buffer-cache reads:   780 MB in  2.01 seconds = 388.89 MB/sec

 Timing buffered disk reads:   70 MB in  3.04 seconds =  23.04 MB/sec

hdparm -d1 -A1 -m16 -u1 -a64 -X69 /dev/hda

/dev/hda:

 setting fs readahead to 64

 setting multcount to 16

 setting unmaskirq to 1 (on)

 setting using_dma to 1 (on)

 setting xfermode to 69 (UltraDMA mode5)

 setting drive read-lookahead to 1 (on)

 multcount    = 16 (on)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 readahead    = 64 (on)

# hdparm -tT /dev/hda

/dev/hda:

 Timing buffer-cache reads:   740 MB in  2.01 seconds = 368.77 MB/sec

 Timing buffered disk reads:  112 MB in  3.03 seconds =  36.97 MB/sec

```

While the default setting (/etc/conf.d/hdparm) is :

all_args="-u1 -m16 -c3"

I could get a great benchmark, 

```

hdparm -tT /dev/hda

/dev/hda:

 Timing buffer-cache reads:   732 MB in  2.01 seconds = 364.23 MB/sec

 Timing buffered disk reads:  124 MB in  3.03 seconds =  40.86 MB/sec

```

Maybe the hd itself knows what is the best, and what we should do

is just enable the ablity in the kernel.

Best regards

----------

