Comment 209 for bug 131094

@Thomas, I can try the 'time cat..' line later but I don't think it will reveal information other than that catting the SATA harddisk is probably faster, because the drive is generally faster (higher capacity per platter, more cache).

@KhaaL, I must say that for the last test I used Anticipatory as queueing mechanism, I found that out jsut before rebooting, but both the PATA and SATA harddisks were set on Anticipatory, and both had the same amount of read ahead set, at that time 4096.

Native Command Queueing can be changed by changing the value of 'queue_depth' for a specific drive. You can find it like this:

cd /sys
find |grep queue_depth

Now the system will report a file like
./devices/pci0000:00/0000:00:0e.0/host2/target2:0:0/2:0:0:0/queue_depth

I will post my findings in

If you look inside that file you can see the value it is on (just 'cat' it) and you can change the value by something like

echo 1 > ./devices/pci0000:00/0000:00:0e.0/host2/target2:0:0/2:0:0:0/queue_depth

If it is already 1, your drive might not support NCQ.

I will post my findings in the other thread later. What I can also try is to make an exact copy of the contents of the SATA drive to an other SATA or PATA drive laying around and see if the sluggishness is different.

@Milan: you might think that the system on SATA is more sluggish than on PATA as it contains the system files, but even just alt-tabbing through windows is sluggish. If I do this with no I/O load on the drive this tabbing through programs does not interact with the disk as all programs are in memory and swap is turned off. When I start the load on the PATA drive the system remains responsive and windows just appear when I alt-tab, perhaps with a short delay, but that is ok. When I start the load on the SATA drive however, the alt-tab may take seconds to complete before the selected window appears. That's strange isn't it? To make sure I want to do the test mentioned above by 'dd-ing' the full SATA drive to the PATA or some other PATA/SATA drive and do the same test on the drive the system boots from.

@Jamie: NCQ might be horrible on the drive, afaik it is one of the first 500 GB 7200.10 drive from Seagate. I can try to update its firmware but if that removes the problem I cannot help out anymore ;). On my 7200.11 1 TB drives (also one of the first 1 TBs on the market) I also disabled NCQ because I found some thread that it might kill the contents of the file system. If you want I can lookup where I found that. I had a problem with my RAID 5 array in a server with these 1 TB disks and contacted the libata maintainers but I had to restore the bad sector before my array was destroyed by not having a spare disk, so after fixing the bad sector I could not reproduce the problem anymore. In the meantime I switched that server to an older kernel, probably a stock kernel from Gutsy or Feisty.

Hendrik: The fact that work on your SATA drive makes the system sluggish, contrary to the PATA one, is normal since your system files are on that drive. Schedulers only deal with processes competing for the same drive access. If the problem is actually with SATA, the only proof we have is that you only changed your drive to SATA, and nothing else.

I'm now at work so I cannot test, but I must say that I have the exact same configuration over here except for a 5000+ processor instead of a 5200+. This machine however has a SATA disk and I never experienced any sluggishness on this machine, so far running Hardy and Intrepid. So the sluggishness may even be drive specific?