Hendrik van den Boogaard wrote: > 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.
That's quite surprising: NCQ should in theory always make it faster, unless you have a terrible drive implementation. > 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. Both of these things (the oopses and the NCQ reduction in performance) ought to be reported to Linux's libata maintainer... -- Jamie -- Heavy Disk I/O harms desktop responsiveness https://bugs.launchpad.net/bugs/131094 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
