lkml.org 
[lkml]   [2009]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: disk speed regression kernel 2.6.29 and after
    Date
    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.


    \
     
     \ /
      Last update: 2009-09-24 19:35    [W:5.793 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site