哪种文件系统可以提供最好的保护，以保护数据免于因断电而损坏？

我运行一个小的uClibc和busybox一个x86设备上基于嵌入式系统。我使用的是initramfs，但是我也在ext3IDE模式下将自定义目录安装在紧凑型闪存设备上，该目录用于存储由自定义编写的c ++应用程序创建的持久性测量记录数据。我选择了ext3文件系统，因为在读过的几本书中（在Karim Yaghmour 撰写的《构建嵌入式Linux系统》和Christopher Hallinan 撰写的《Embedded Linux Primer》）中，在IDE模式下使用CF驱动器时，建议使用该文件系统来防止电源丢失。这尤其重要，数据也很关键。

但是，由于我上一个问题中的一些评论，即在文件写入过程中发生断电时如何还原损坏的ext3文件的混淆，看来实际上该文件系统不能提供防止由于电源引起的数据损坏的安全性的保证。失利。所以我想知道

1. 是否ext3实际上是这个设置的最佳选择？
2. 光盘写入操作期间的断电是否只会定期破坏我要追加到文件中的部分数据，还是会破坏整个文件？
3. 断电时未写入的数据是否完全安全？特别是，我的initramfs.cpio文件也可能会损坏吗？
4. 我是否可以在应用程序代码中使用任何方法来保护数据（即创建一个额外的分区并将数据写入镜像，以便始终有2个副本）-对于我的应用程序而言，速度并不是真正的问题，因此复制操作成本很高是可以接受的。

我已经阅读并阅读了以下相关问题的答案：日志文件系统是否可以保证在电源故障后不会损坏？，但并没有涵盖使我感到困惑的某些事情。

我意识到我在问很多问题，但似乎尽管阅读了很多材料，但是在断电的情况下，我还是根本无法理解我的数据所带来的风险。

与所有与安全有关的事物一样，没有任何保证，但您还需要在风险（和成本）与概率之间取得平衡。根据经验（自黑暗时代起我就运行过数十个* nix boxen），我从未真正遇到过因电源导致的重大文件损坏。

其中一些机器甚至在非日志文件系统（通常是ufs和ext2）上运行。其中有些是嵌入式的，而有些则是诺基亚N900之类的手机-因此根本无法保证良好的电源。

这并不是说文件系统损坏不会发生，只是发生的可能性足够低而不必担心您。不过，没有理由不对冲您的赌注。

在回答您的字面问题时：

1. 至少您所参考的第一本书是在以前写的ext4-当作者建议使用时ext3，他们实际上是在说：“不要使用像ext2'）这样的不稳定或非日志文件系统。试试看ext4，它已经相当成熟，并且对于非旋转磁盘有一些不错的选择，这可能会延长闪存设备的预期寿命。
2. 可能会丢失最后一两个块，而不是整个文件。对于日志文件系统，这将是唯一的损失。在某些失败情况下，我可以看到随机数据散布在文件上，但看起来就像微陨石直接通过嵌入式设备粉碎一样。
3. 参见2。没有什么是100.00％安全的。

4. 如果您有第二个IDE通道，请在其中插入第二个CF卡，并定期获取文件系统的备份。有几个方法可以做到这一点：rsync，cp dump，dd，即使使用md(4)（软件RAID）设备（添加第二个驱动器偶尔，让它同步，然后将其删除-如果两个设备都是活的时候，它们运行同样的风险文件系统损坏）。如果使用LVM，甚至可以抓取快照。对于数据收集嵌入式设备，我只使用临时解决方案，该解决方案将挂载第二个文件系统，复制到数据日志上，然后立即将其卸载。如果您担心该设备的启动映像良好，请将第二个启动管理器副本和所有必要的启动映像粘贴在第二个设备上，并将计算机配置为从任一CF卡启动。

   我不会在同一设备上信任第二个副本，因为存储设备比稳定文件系统更容易发生故障。很多更多的时候，在我的经验，到目前为止（在工作中，人们为周五下午磁盘故障惊人地高的机会苦半玩笑。这几乎是一会儿每周的事件）。无论磁盘是否旋转，它都可能发生故障。因此，如果可以的话，请将鸡蛋放在两个篮子里，这样可以更好地保护数据。

   如果数据特别敏感，我将定期访问该设备，将备份CF换成新的CF，然后重新启动，以使其fsck所有文件系统处于良好状态。

在我看来，在突然断电的情况下，文件系统实现所能实现的功能是有限的-毕竟，它实际上是与硬件接口的，因此在将数据/指令发送到硬件的时间与何时将其之间发生了什么？得到响应是无法控制的。如果有一个文件系统可以解决此问题，您将听说过它。

因此，保护​​关键数据的策略将从硬件级别的决策（例如使用不间断电源）中受益最多。在您的情况下，这可能不太可行。

您已经说过性能并不是真正的大问题，因此请明智地使用fsync()。

光盘写入操作期间的断电是否只会定期破坏我要追加到文件中的部分数据，还是会破坏整个文件？

我多年来一直在个人和中低流量的Internet服务器上使用extN文件系统，并且像Alexios一样，由于电源故障，我也没有看到太多损坏（尽管公平地说，服务器具有UPS，我不记得了其中之一实际上会沿这种方式下降）。一个更严重的问题是硬件故障造成的损坏，不同的文件系统可能（再一次）具有越来越多的能力来解决该问题，但是（再一次），这基本上超出了他们的控制范围，因此它们无法避免。

我偶尔看到文件丢失或被截断为零大小。我认为这些很有可能会以某种方式恢复。对我而言，这是不必要的，因为它们已备份。在大多数情况下，如果发生任何错误，fsck似乎都可以解决。

断电时未写入的数据是否完全安全？特别是，我的initramfs.cpio文件也可能会损坏吗？

我认为，仅因电源故障而造成的风险确实非常低，但闪存损坏的类型可能会因电源故障而引起的电涌而遭受损失-我没有经验，但希望您考虑过并对此进行了研究。

我可以在应用程序代码中使用任何方法来保护数据吗？

值得重复关于fsync（）的观点。C ++ / iostream对象没有为此的方法（:: flush和:: sync不是fsync），但是您只需要一个文件描述符。

ZFS绝对是一种通过设计防止损坏的文件系统，并且可能是唯一的文件系统。但是，我不确定基于uClinux平台的ZFS实现（基于保险丝还是本机）的可用性。

至少有一个商业文件系统能够出色地完成工作，以确保文件系统几乎不会由于电源故障而损坏，并且唯一可能丢失的数据是在断电时添加的数据。

不利的一面是，它非常昂贵，而另一方面，它们提供了强大的支持。由于费用高昂，对于高风险和/或大批量产品而言，这实际上是唯一的选择。像石油和天然气生产中的关键嵌入式设备一样，需要在“不确定”的运行条件（例如频繁停电等）内确保系统完整性。

查看DataLight（公司）和/或产品“ Reliance NITRO ”。（信赖是他们的传统和安全但不是很有效的解决方案，已由 Reliance NITRO）。即使您没有钱使用此系统，他们也有一些不错的文章讨论它们的系统如何工作，为什么它比ext3和ext4更可靠。

我很抱歉，如果读起来像是广告，只想指出选项。