Comment 208 for bug 131094

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