There was in fact a slight error in our Percona Server 5.1 implementation when an I/O error occurred during write. This has been corrected and should appear in our next 5.1 release.
In our Percona Server 5.5 implementation (lp:~gl-az/percona-server/5.5-686534-881001), which should also become available soon, we implemented similar functionality but also working with multiple buffer pools. The implementation will iterate through the buffer pools, dumping each and only holding the current buffer pool mutex while populating the dump page. We also modified some of the dump page logic to allow the number of dump pages to fill for each mutex cycle to be changed at compile time. The default is one page.
The math posted above by Laurynas is slightly flawed though by an initial typo that changes the rest of the math. Each record is 8 bytes (space id, page id). Using default InnoDB page size of 16K means each dump page will hold 2048 LRU records worth of dump, not 4096KB of records.
This fix should have the effect of relieving stalls due to lengthy holding of the buffer pool mutexes at the possible expense of creating more context switching around those mutexes during dump. This can be reduced by increasing the number of dump pages filled for each mutex cycle by either changing the new #define and recompiling or by exposing that value as yet another system variable, but we will leave that for another day.
