我的设备上有一个 TinyCore (3.6) Linux 发行版，它使用模块磁盘或紧凑型闪存存储。
文件系统是ext2。
我在此设备上有一个 LAMP 堆栈，并且正在使用包含 400 多个表 (myisam) 的 MySQL 数据库。写入操作每 15 分钟系统地发生一次。
这些表是由我的 Web 应用程序根据我的设置需要生成的。
现在，由于缺乏电力，该设备可能会突然关闭。
发生的情况是，如果 MySQL 正在执行某些写入操作（即update、delete、insert），则某些数据和索引文件可能会损坏。
这当然没什么大不了的，但是执行repair table手术也没有那么糟糕。表被修复，应用程序可以继续运行，即使不幸的是一些数据丢失了（在我的情况下这是可以接受的）。
问题是，通常，当发生突然关闭时，几个 mysql 表文件（FRM 或 MYI 或 MYD）处于“输入/输出错误”状态，并且我的 MySQL 前端报告“存储引擎错误 5”（I/ O 错误）对于这些表。使用数据库的应用程序显然无法正确运行。
我不想阻止类似的事件（我认为在某种程度上是不可避免的），我想考虑一些正确且可能自动从上述场景派生的文件 I/O 错误情况中恢复的方法。
有任何想法吗？
编辑： 不幸的是，我无法切换到 ext3，我必须坚持使用 ext2，也是因为 ext3 会严重影响固态内存写入周期。
答案1
我认为如果你使用CF，则不可能使用DM多路径或者其他更高可用性的功能，那么您至少应该使用“noatime”选项挂载这些文件系统，以延长寿命（您自己的脚本不依赖atime等）。
除此之外，它听起来并不是最强大的平台。