Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: disk speed regression kernel 2.6.29 and after | Date | Thu, 24 Sep 2009 19:34:27 +0200 |
| |
On Thursday 24 September 2009 18:26:45 Will wrote: > On Thu, 24 Sep 2009 14:26:49 +0200 > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > > > > > > > I don't see how could commit 295f00 be the guilty one here. I'm suspecting > > that bisection went wrong at some point (easy to verify by checking if commit > > 295f00^1 is also bad). > > > > PS Will, it would be useful to try libata first and possibly rule out PATA out > > of the picture completely. > > Disabling "ATA/ATAPI/MFM/RLL" restored my performance completely, with the > newer kernels. I'll just have to get used my other hard drives being sdb . . .. > Thanks guys. The copy takes right at 3m30s now. > I made a change to dd years ago to make it default to 1 meg block size and to show > me the "Megs copied" on screen, so I can watch how fast dd is going. With the > older atapi drivers, this copy would be fast, but jerky and halting. With kernel > 2.6.29 and after the halts were more frequent and longer, dragging the copy out > to over 9 minutes in this case. With only the libata enabled, the "megs copied" > is very smooth, with no halting, though still right at 3m30s. > If you need me to test anything for the sake of the older drivers, I can. > Thanks again for the help.
I'm glad to hear that the issue is fixed for you.
Regarding additional pursue of the root cause, I think that it is not worth the effort currently since there were no other reports about similar problems and libata is a better solution on most modern systems anyway.
| |