我正在x86 设备上运行一个小型uClibc嵌入式系统。busybox我正在使用 initramfs，但我还在ext3IDE 模式下的紧凑型闪存设备上安装了一个自定义目录，我用它来存储由自定义编写的 C++ 应用程序创建的持久测量日志记录数据。我选择ext3文件系统是因为在我读过的几本书中建议使用它以防止在 IDE 模式下使用 CF 驱动器时断电（构建嵌入式 Linux 系统作者：卡里姆·亚格莫尔和嵌入式 Linux 入门作者：克里斯托弗·哈利南）。这一点尤其重要，数据至关重要。
但是，由于我之前问题中的一些评论如果在文件写入期间发生断电，则对如何恢复损坏的 ext3 文件感到困惑事实上，该文件系统似乎并不能提供针对因断电而导致的数据损坏的安全保证。所以我想知道是否
- 实际上是
ext3这种设置的最佳选择吗？ - 光盘写入操作期间的断电是否只会损坏我定期附加到文件的数据部分，或者是否会损坏全部的文件？
- 数据是不是在断电时写入完全安全吗？特别是，我的
initramfs.cpio文件是否存在损坏的风险？ - 有没有什么方法可以在我的应用程序代码中使用来保护数据（即创建一个额外的分区并将我的数据写入镜像，以便始终有 2 个副本）-速度对于我的应用程序来说不是真正的问题，因此昂贵的复制操作是可以接受的。
我已经看到并阅读了这个相关问题的答案：日志文件系统能否保证断电后不会损坏？，但它并没有完全涵盖一些让我困惑的事情。
我意识到我问了很多问题，但似乎尽管阅读了大量材料，但我从根本上未能理解断电时数据的风险。
答案1
与所有与安全相关的事情一样，没有任何保证，但您还需要平衡风险（和成本）与概率。根据经验（自黑暗时代以来我一直在运行数十个 *nix boxen），我从未真正遇到过由电源导致的文件系统损坏。
其中一些机器甚至在非日志文件系统（通常是 ufs 和 ext2）上运行。其中一些是嵌入式的，还有一些是像诺基亚 N900 这样的手机，因此根本无法保证良好的电源供应。
这并不是说文件系统损坏不会发生，只是发生的可能性足够低，您不必担心。尽管如此，没有理由不对冲你的赌注。
回答你的字面问题：
- 至少您引用的第一本书是以前写的
ext4- 当作者建议使用时ext3，他们实际上是在说“不要使用不稳定或非日志文件系统ext2”）。尝试一下ext4，它非常成熟，并且对于非旋转磁盘有一些不错的选项，可以延长闪存设备的预期寿命。 - 它很可能会丢失最后一两个块，而不是整个文件。对于日志文件系统，这将是唯一的损失。在某些故障场景中，我可以看到随机数据散布在文件中，但它们看起来就像微陨石直接粉碎嵌入式设备一样。
- 请参阅 2。没有什么是 100.00% 安全的。
如果您有第二个 IDE 通道，请将第二个 CF 卡插入其中并定期获取文件系统的备份。有几种方法可以做到这一点：
rsync，，，甚至使用（软件 RAID）设备（您偶尔添加第二个驱动器，让它同步，然后将其删除 - 如果两个设备始终处于活动状态，则它们会面临相同的cpdump风险文件系统损坏）。如果您使用 LVM，您甚至可以抓取快照。对于数据收集嵌入式设备，我只使用临时解决方案，它安装第二个文件系统，复制数据日志，然后立即卸载它。如果您担心设备是否具有良好的启动映像，请将启动管理器的第二个副本以及所有必要的启动映像粘贴到第二个设备上，并将计算机配置为从任一 CF 卡启动。ddmd(4)我不会相信第二份副本相同的因为存储设备比稳定的文件系统更容易发生故障。很多根据我迄今为止的经验（在工作中，有一个半开玩笑的说法是，星期五下午磁盘故障的可能性高得惊人。有一段时间，这几乎是每周一次的事件）。无论磁盘是否旋转，它都可能发生故障。因此，如果可以的话，把鸡蛋放在两个篮子里，这样你就能更好地保护你的数据。
如果数据特别敏感，我会定期访问该设备，将备份 CF 更换为新的 CF，然后重新启动，以
fsck充分利用其所有文件系统。
答案2
在我看来，文件系统实现在突然断电的情况下所能实现的功能是有限的——毕竟，它实际上是在与硬件进行交互，所以在它向硬件发送数据/指令的时间和它发送数据/指令的时间之间会发生什么？得到回应是不受其控制的。如果有一个文件系统可以绕过这个问题，您一定听说过。
因此，保护关键数据的策略将从基于以下方面的决策中获益最多：硬件水平，例如，通过使用不间断电源。在您的情况下这可能不太可行。
你说过性能并不是一个大问题，所以要明智地使用fsync()。
光盘写入操作期间的断电是否只会损坏我定期附加到文件的部分数据，还是会损坏整个文件？
多年来我一直在个人和中低流量互联网服务器上使用 extN 文件系统，并且像 Alexios 一样，我没有看到由于电源故障而导致的太多损坏（尽管公平地说，服务器有 UPS，我不记得了其中一个实际上是这样走的）。一个更严重的问题是硬件故障造成的损坏，不同的文件系统可能（再次）或多或少地处理该问题的能力，但是（再次）这从根本上超出了他们的控制范围，他们无法阻止它。
我偶尔会看到文件丢失或截断为零大小。我认为这些很有可能会以某种方式恢复；这对我来说没有必要，因为它们已备份。大多数时候，如果出现任何问题，似乎fsck都会解决它。
断电时未写入的数据是否完全安全？特别是，我的 initramfs.cpio 文件是否也有损坏的风险？
我认为仅因电源故障而造成的风险确实非常低，除了由于电源故障可能导致的电涌而导致闪存存储损坏的情况之外——我没有这方面的经验，但希望您已经考虑过并对此进行了研究。
我可以在应用程序代码中使用任何方法来保护数据吗？
值得重复的一点是fsync()。 C++/iostream 对象没有此方法（::flush 和 ::sync 不是 fsync），但您需要的只是一个文件描述符。
答案3
ZFS 绝对是一种通过设计防止损坏的文件系统，并且可能是唯一的一个。但是，我不确定 ZFS 实现（基于熔丝或本机）对于基于 uClinux 的平台的可用性。
答案4
至少有一种商业文件系统可以发挥巨大作用，确保文件系统几乎不会因电源故障而损坏，并且唯一可能丢失的数据是断电时添加的数据。
缺点是它非常昂贵，但好的方面是它们提供了很大的支持。由于费用高昂，它实际上只是高风险和/或大批量产品的选择。例如石油和天然气生产中的关键嵌入式设备需要在“不确定”的操作条件（例如频繁断电等）下确保系统完整性。
查看数据光（公司）和/或产品“信实硝基“。（依赖是他们的遗产，是安全但不是非常有效的解决方案，被取代信实硝基）。即使您没有钱使用这个系统，他们也有一些非常好的文章讨论他们的系统如何工作，为什么它比 ext3 和 ext4 等更可靠。
如果这读起来像广告，我很抱歉，只是想指出一些选项。