Acho que na maioria das vezes isso foi resolvido. Meu desempenho sob IO pesado melhorou em 2.6.36 e espero que ele melhore mais em 2.6.37. Veja estes phoronix Artigos.
Wu Fengguang and KOSAKI Motohiro have published patches this week that they believe will address some of these responsiveness issues, for which they call the "system goes unresponsive under memory pressure and lots of dirty / writeback pages" bug. Andreas Mohr, one of the users that has reported this problem to the LKML and tested the two patches that are applied against the kernel's vmscan reported success. Andreas' problem was the system becoming fully unresponsive (and switching to a VT took 20+ seconds) when making an EXT4 file-system when a solid-state drive was connected via USB 1.1. On his system when writing 300M from the /dev/zero file the problem was even worse.
Aqui está um link direto para o bug
Também do Phoronix
Fortunately, from our testing and the reports of other Linux users looking to see this problem corrected, the relatively small vmscan patches that were published do seem to better address the issue. The user-interface (GNOME in our case) still isn't 100% fluid if the system is sustaining an overwhelming amount of disk activity, but it's certainly much better than before and what's even found right now with the Linux 2.6.35 kernel.
Há também o anúncio de lançamento do Phoronix 2.6.36
as barreiras dos blocos estão desaparecendo e isso também deve ajudar no desempenho.
In practice, barriers have an unpleasant reputation for killing block I/O performance, to the point that administrators are often tempted to turn them off and take their risks. While the tagged queue operations provided by contemporary hardware should implement barriers reasonably well, attempts to make use of those features have generally run into difficulties. So, in the real world, barriers are implemented by simply draining the I/O request queue prior to issuing the barrier operation, with some flush operations thrown in to get the hardware to actually commit the data to persistent media. Queue-drain operations will stall the device and kill the parallelism needed for full performance; it's not surprising that the use of barriers can be painful.
Há também este artigo do LWN sobre programação de I / O justa
Eu diria que o IO reavivado como um grande negócio sobre o tempo do lançamento do ext4 em 2.6.28. Os links a seguir são para versões do Linux Kernel Newbies , você deve revisar as seções Block, e Filesystems. Isso pode, é claro, ser um sentimento injusto, ou apenas o tempo que eu comecei a ver o desenvolvimento do FS, tenho certeza que ele tem melhorado o tempo todo, mas eu sinto que alguns dos problemas do ext4 fizeram com que as pessoas olhassem com força para a pilha de IO, ou pode ser que eles esperassem que o ext4 resolvesse todos os problemas de desempenho e, quando isso não aconteceu, eles perceberam que precisavam procurar em outro lugar os problemas.
2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37