I have a TinyCore (3.6) Linux distribution on a device of mine, which uses disk-on-module or compact flash storage.

The filesystem is ext2.

I have a LAMP stack on this device and I'm playing with a MySQL database containing over 400 tables (myisam). Write operations occur systematically every 15 minutes.

These tables are generated by my web application, according to my setup needs.

Now, it happens that this device can be abruptly shut down, due to lack of power.

What happens is that, if MySQL is performing some write operation (i.e. update, delete, insert) some of the data as well as index files can be corrupted.

It's no big deal for sure, but performing a repair table operation is not that bad; tables are repaired and applications can continue running, even if unfortunately some data is lost (which in my case could be acceptable).

The problem is that, often, when an abrupt shutdown occurs, several mysql table files (FRM or MYI or MYD) are in "Input/Output error" status and my MySQL front-end reports a "storage engine error 5" (I/O error) for those tables. Applications using the database are obviously unable to run correctly.

Rather than to prevent events like those ones (which I think are unavoidable at some extent) I would like to think about something to correctly and possibly automatically recover from file I/O error situations deriving from scenarios described above.

Any ideas?

EDIT: Unfortunately I can't switch to ext3, I must stick with ext2, also due to the fact that ext3 would heavily affect solid state memory write cycles.

  • Is the file system fixed, or are you able to change it? Any journaling file system should be able to deal less poorly with sudden shutdowns, and ext3 should be a drop-in replacement for ext2 in essentially any situation. – a CVn Oct 3 '13 at 9:56
  • @MichaelKjörling unfortunately I can't switch to ext3; I must stick with ext2, also due to the fact that ext3 would heavily affect compact flash or disk-on-module write cycles. – BerserkEVA Oct 3 '13 at 10:04
  • Does CF have no wear leveling? – Gilles 'SO- stop being evil' Oct 3 '13 at 22:47

I think if you're using CF, with no possibility to use DM-MultiPath or other higher-availbility features, then you should at least be mounting those filesystems with the "noatime" option, to prolong life (where you don't rely on atimes for your own scripts, etc...).

Other than that, it doesn't sound like the most robust of platforms..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.