Hard drives causing painful slowdown

**dan@george** · 02-10-2005

So my hard drives (I have two 160 GB 7200 RPM ATA ones) are becoming a problem. Whenever a lot of data is being written to them (i.e. whenever I copy a large file from one drive to another or from a network mounted share to one of my drives), my computer basically grinds to a halt. Music starts skipping, my wireless keyboard sends nonsense signals when I type, and all sorts of unpleasant experiences assail my fragile little brain.

This happens even if I use, say,

Code:

nice -n 30 cp drive1/movie.avi drive2/

so I assume it's not a processor problem. The benchmark of hdparm is as follows:

Code:

dan@george&#58;~# hdparm -tT

 Timing buffer-cache reads&#58;   2196 MB in  2.00 seconds = 1097.62 MB/sec
 Timing buffered disk reads&#58;   22 MB in  3.04 seconds =   7.23 MB/sec

and as far as I know, those numbers are pretty good.

Can anybody think of what might relieve this awful bottleneck? This is a Slackware system with kernel 2.6.7.

**dan@george** · 02-10-2005

OK, here's an update, as well as a bump:

My hard drives weren't set up to use DMA. So I tried

Code:

# hdparm -d1 /dev/hda

/dev/hda&#58;
 setting using_dma to 1 &#40;on&#41;
 HDIO_SET_DMA failed&#58; Operation not permitted
 using_dma    =  0 &#40;off&#41;

What's that?! I'm root! You must permit me all operations!

But fine. I Googled this problem, and the results seemed to suggest that the kernel had been compiled without DMA support for my chipset. And sure enough, it had been! So I recompiled the kernel with the correct DMA support, booted up, and got the exact same error. Total bummer. Anyone think of anything yet?

**sarumont** · 02-11-2005

The *exact* same error? Maybe your hard drives aren't DMA compatible...

Seriously, though, does it work on /dev/hdb?

**valan** · 02-11-2005

I got that exact same problem when tryin to set up hdparm today. Won't let me turn dma on, even though 'hdparm -i' shows that it's available, and still says operation not permitted when I try to tell it which dma to use with -X. No idea what cause this could be, dma IS enabled in the kernel.

**Stormblazer** · 02-11-2005

I had the same problem, it was fixed easily enough:
Recompile the kernel again, but this time make sure the support for your chipset is compiled into the kernel (NOT as a module).
And of course check that "enable DMA by default" is enabled in the kernel too.

**dan@george** · 02-11-2005

Thanks sarumont and Stormblazer:

I had compiled the support for my chipset directly into the kernel in the first place, and "Use PCI DMA by default when available" was also checked. The hdparm -d1 /dev/hdb returns the exact same error, and so does hdparm -d1 /dev/hdc, which is my CD/DVD drive. Pretty infuriating, huh?

**sarumont** · 02-11-2005

Originally Posted by dan@george

Thanks sarumont and Stormblazer:

I had compiled the support for my chipset directly into the kernel in the first place, and "Use PCI DMA by default when available" was also checked. The hdparm -d1 /dev/hdb returns the exact same error, and so does hdparm -d1 /dev/hdc, which is my CD/DVD drive. Pretty infuriating, huh?

Here's a thought...have you tried upgrading to a newer version of hdparm?

**valan** · 02-11-2005

I know that my kernel has this stuff compiled in, I don't mess with modules for IDE stuff, since they are a bit slower. I'm probably not running the latest version of hdparm though, but I'll worry about this later, since I plan on building LFS 6 soon, I'm still running 5.

**dan@george** · 02-11-2005

So I upgraded from hdparm v5.5 to v5.9, but the error persists. Incidentally, I was able to enable 32 bit transfer mode with the special sync sequence using

Code:

# hpdarm -c3 /dev/hd&#123;a,b&#125;

which sped up my buffered disk reads by about a factor of 2.

That slowdown's still going on. I checked the info from hdparm on my disks, and got this:

Code:

# hdparm -i /dev/hda

/dev/hda&#58;

 Model=SAMSUNG SP1604N, FwRev=TM100-24, SerialNo=0731J1FWC10112
 Config=&#123; HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs &#125;
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO=&#123;min&#58;240,w/IORDY&#58;120&#125;, tDMA=&#123;min&#58;120,rec&#58;120&#125;
 PIO modes&#58;  pio0 pio1 pio2 pio3 pio4 
 DMA modes&#58;  mdma0 mdma1 mdma2 
 UDMA modes&#58; udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to&#58; &#40;null&#41;&#58; 

 * signifies the current active mode

Now since * is supposed to signify the currently active DMA mode, this output would seem to suggest that my drive is currently operating under UDMA5. However,

Code:

hdparm -d /dev/hda

/dev/hda&#58;
 using_dma    =  0 &#40;off&#41;

Pretty strange, if you ask me. But I suppose you shouldn't, because I'm asking you.

Thread Tools

Display

Hard drives causing painful slowdown

Posting Permissions