| 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
| ||
|
Message-Id: <20090924112645.dc97dd07.whansard@sbcglobal.net> Date: Thu, 24 Sep 2009 11:26:45 -0500 From: Will <whansard@...global.net> To: linux-kernel@...r.kernel.org Subject: Re: disk speed regression kernel 2.6.29 and after 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. -- 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