innodb_force_recovery is more efficient with InnoDB plugin than XtraDB on certain cases

This "bug" is XtraDB related but it could be interesting to put in the KB the fact that trying to restore/access damaged InnoDB datas could work differently when using XtraDB or InnoDB plugin.

It is the second time that i have a serious power shortage on a server with a RAID card with wright through cache enabled and that has its battery depleted (the RAID card flushes its cache to disk not on a FIFO manner) with InnoDB tables on a MariaDB 5.5 ending up badly corrupted and i encounter this very issue.

These tables are write intensive as they store monitoring datas.

The only way to start the server is to set innodb_force_recovery = 6 and to disable XtraDB and load InnoDB plugin instead.

Setting the innodb_force_recovery to any parameter with XtraDB will end up on either the server crashing at start (with values from 1 to 5 in my case) either with this messages looping in the error log while stays still unavailable : InnoDB: Waiting for the background threads to start

Here are the kind of errors shown on the error log when starting with innodb_force_recovery = 6 and InnoDB plugin :

130711  3:09:36  InnoDB: error: space object of table 'zabbix/acknowledges',

InnoDB: space id 10 did not exist in memory. Retrying an open.

130711  3:09:36  InnoDB: Warning: allocated tablespace 10, old maximum was 0

130711  3:09:36  InnoDB: error: space object of table 'zabbix/actions',

InnoDB: space id 11 did not exist in memory. Retrying an open.

130711  3:09:36  InnoDB: error: space object of table 'zabbix/alerts',

Accessing certain rows on certain tables will crash MariaDB but at least the other tables can be dumped completely and these tables can also be partially dumped using a LIMIT clause.