Ok, i said this was gonna be quick, so here goes. Why is it that when I am downloading something lets say at 200 kbps from the internet. My Ethernet connection shows a constant download of 200 kbps. However the problem comes to when my hard drive decides it wants to put that information on the disk. It does it in chunks.... it does nothing for about 5 seconds, and then writes an almost 2MB chunk to my hard drive causing my CPU usage to jump to process it all. Then it goes to doing nothing for about 5 seconds, and then writes almost 2MB again. Why is my hard drive doing this? Any Ideas?

Thanks,
DragonM15

My first guess would be that it has something to do with the size of the cache on the hard drive?

According to hdparm the buffer is about 7500kb. Is there a way to make it not do those big chunks how it does?

After a quick scan through the hdparm man page, it looks like the -W option allows you to control write caching. I honestly have no idea if this applies to your situation, but I think it makes sense that the cache would be the cause of this behavior.

"Then it goes to doing nothing for about 5 seconds"

The kernel flushes the hard disk caches every 5 seconds. That's just the way it works.

Ok, so using hdparm wont fix this, and so there is no way to fix it? What it does is it doesnt do nothing every 5 seconds, it sits for about 5 seconds doing nothing and then writes a 2 meg chunk (this takes approx 1 sec), then sits for 5 seconds.... not write for 5 seconds, then do nothing for 1.... the way you wrote that it makes it sound the exact opposite of what mine is doing.

DragonM15

If it is the kernel, it looks like with 2.6 you can set the commit interval using sysctl. I don't fully understand it, but if you do some searching, it looks like you might have some options.

If DMA is enabled it shouldn't bury the processor.

Shortening commit times generally will decrease overall system performance since the HD is the slowest component in the system.

"Ok, so using hdparm wont fix this, and so there is no way to fix it?"

You should try hdparm anyway. If dma or 32 bit is not enabled, then the disk subsystem is taking a lot more realtime than it should. Here's my hdparm string. It made a real difference on my system. Do your research on -Xudma6 before you use it.

I ran this command and received the following output:
So, I am using UDMA6, so what is the difference between UDMA and DMA? Can you use both? If so, then I have tried enabling PIIX/ICH for my IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller. However, I realize that enabling PIIX causes the kernel to recognize my HD as instead of being hda it ends up being sda. Before I reboot I edit my fstab so that all partitions are sda. However whenever I reboot I get that retarted kernel panic: cannot mount partition (3,0) or something similar to that. I cant remember it exactly. So then i have to reboot in PHLAK (live distro) and changing my fstab back to how it was in order to boot into my previous kernel config.

I can post my kernel config if you would like. However, that command that I tried seemed to help a little bit. So if you have any questions, or comments, please Do tell.

Thanks,
DragonM15

It's strange that DMA wasn't enabled on the drive, but that's the way the cookie crumbles. You can see what actually took by running "hdparm /dev/hda" You can get more info about what's going on by running "hdparm -i /dev/hda". It may be the case that udma4 is the max the drive will use and that's what actually got set. The only thing I know about udma is that it's called ultra dma, and it's faster. Other than that, I know zip.

What brand/model drive is this? And is this a laptop or what?

You'll need to fix both fstab and grub before you can do the switch to sda1. I've never run SATA on that controller, so I can't say one way or the other.

so udma is better than DMA.... ok, thats great.... and my drive uses udma6 not 4.... This is a laptop. Dell Inspiron 9300 to be exact, with a Hitachi HTS541080G9AT00. I noticed that the drive keeps the settings from the command, however upon restart it wipes those out with these:
And after I give it the command listed above it goes to this:
I have tried modifying fstab, and my lilo config (I dont use grub, I have Slackware 11.0) However, if I change it to say root = /dev/sda4 like it is supposed to when i change the kernel config with those new settings, you are REQUIRED to run lilo so it can look through that config file to ensure everything is correct. Well, before I reboot, it still thinks my root to be /dev/hda4 and there is no device on /dev/sda. So it freaks. I think oh well maybe i can restart anyways and it will look at that config file ANYWAYS, but it doesn't. It goes from the last time lilo was ran to check over that config file and passed.... I dont know of any other way to describe it.

I did some more looking around, and with ICH6 support enabled in the kernel, this allows for you to enable DMA, the only catch is that by doing so you switch all hda hard drives to sda. However, if you enable the generic IDE (which is what i am using) it will work, but without DMA, also the hard drive will be known as hda. If you enable both of these options in the kernel the generic will take presidence over the ICH6 support. In order to make ICH6 support to be used at boot you must give the kernel boot option of hda=noprobe. I tried this and it crashes because all of my configs look towards hda as the hard drive name.

I had a thought that if I backup the /dev/sda's that I need as sda.back, sda1.back, etc. then making a link to hda from the sda's so I can configure lilo to have sda's and it wont error out.

After doing this, I boot up into a live distro, edit my linux hard drive, deleting the links to hda and restoring all my sda's so it will look at the real sda's when booting. I thought it was a genius idea. However, the kernel crashed on boot anyways.... So much for my genius idea :S

DragonM15

P.S. Any ideas would be greatly appreciated. If this idea of mine didn't make sense to you, let me know and I will try to explain better.