lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200909241934.27472.bzolnier@gmail.com>
Date:	Thu, 24 Sep 2009 19:34:27 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	whansard@...global.net
Cc:	linux-kernel@...r.kernel.org
Subject: Re: disk speed regression kernel 2.6.29 and after

On Thursday 24 September 2009 18:26:45 Will wrote:
> On Thu, 24 Sep 2009 14:26:49 +0200
> Bartlomiej Zolnierkiewicz <bzolnier@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ