Comment 204 for bug 131094
Revision history for this message
| Hendrik van den Boogaard (chasake) wrote | #204 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Update: running with 'mem=512m' seems to make performance just as bad as on older/other kernels. Then I recalled some information about native command queueing (thanks for the hint on your picture Jamie :)) and how this could trash your disk on some older drive models. I already disabled it on my fileserver a couple of months/years ago and now tried the following:
Copy the large files in one window (PATA -> SATA) and do a 'find /' (SATA drive) in the other window. I found out that the 'find' command is a *lot* more responsive pushing file names to the screen when I put the NCQ buffer on 1 item (effectively disabling NCQ). The mouse and cursor still lock up often for less than a second and performance is still sluggish but the machine is not completely unusable. While I am typing this I put the NCQ setting back to 31 as it was on before but now I cannot even type this complete sentence without seeing it appear on the screen. As far as I can remember somewhere in the 2.6.1x kernels NCQ was added together with all the new libata stuff (that's for me when a lot of trouble started; a bad sector on a disk created kernel-oopses on another NVidia based computer with a 4TB software Raid5 Array). This might also explain why I have not seen this problem before as my old 160G drive is PATA and has no NCQ.
I am wondering if anyone else tried this or can verify this against my experiences.
Another interesting observation: When I 'cat * > /de/null' from the large files directory on the SATA disk performance is sluggish, tabbing through windows is slow to unbearably slow. When I do the 'cat * > /de/null' on the PATA drive there is no sluggishness AT ALL! The swap was turned off to make sure that alt-tabbing would not load paged-out data from the SATA disk, but even after turning swap over to the PATA disk, performance stayed the same when catting on the PATA disk. Same for xfs_fsr defragmentation on SATA: slow and sluggish (also, but a bit less with NCQ off) and on PATA my GUI just remains responsive!
So afterall this really seems to SATA related!