永不中断的文件系统（可接受数据丢失）

Question

围绕这个问题有几个现有的主题，但我所寻求的略有不同。我在嵌入式 Linux 上有一张 SD 卡，但它断电了。我也许可以在某个时候修改硬件，正确关闭等等。但现在，我只想找到一个文件系统，它可以在断电后毫不费力地幸存下来。数据丢失是可以接受的。我不想丢失比我当前正在编写的文件更多的文件，但我仍然宁愿丢失所有文件，也不愿面对“无法挂载”、“等待 10 分钟 fsck”或“无法创建新文件”文件由于此 inode 出现某些错误'。节目必须继续！

我正在努力确保这一点。我正在使用工业级组件，我有硬件看门狗，软件看门狗，内部，外部，init 重新启动程序，守护进程不断检查内存、文件描述符等等，我让看门狗看着我的看门狗，而其他看门狗又在看...但我似乎不能保证SD卡能够挂载和运行？

我现在最好的选择是在 SD 卡上使用 JFS，在我的安装中包含 fsck 和 fsck.jfs。（增加 600kb+ 占用我的内存和闪存。这很糟糕。）并在每次启动时运行 fsck（可能会增加很多启动时间。这有点糟糕。）。不过好像有点难过。

有谁知道更好的方法或更好的文件系统？

更新：在我的发行版中编译 e2fsprogs-libs（对 jfsutils 的依赖）似乎非常困难。我会研究 ZFS（虽然它不是我的发行版的原生。它似乎做了很多我不需要的事情。）

UPDATE2：有关我的系统和我的测试的更多信息：SD 卡存储是辅助的可选存储。SD 卡是 2Gb-8Gb 工业级 microSD。SD 卡是通过我的 rc 使用 mount -t 命令挂载的。选项“noatime”而不是“sync”。我的发行版是一个定制的模拟设备风格的 uClinux，有一个 3.10 内核和一个 1.21 busybox。我的主要存储是带有 jffs2 的 spi 闪存。我从来没有遇到过任何问题。我什至不知道是否有可用的 fsck.jffs2。另一方面，Nand flash ...但那是另一回事了。SD 卡的用途是存储测量数据。“监控”程序会将结果附加到文件中，并具有战略性的同步位置。当文件超过给定大小时，将创建一个新文件。当达到给定数量的文件时，最旧的文件将被删除。如果当前测量文件因断电而丢失，也不是灾难。文件通常为 50-100kb，1 个结果通常为 1kb。这只是最初的开发阶段。没有什么是固定的。这是我第一次在嵌入式系统中处理非闪存文件系统。（我的 x86 服务器上有 ext4。）

我从 vfat 开始。默认文件系统。（我认为工厂可能有选择它的理由。如果一切正常，我真的不太在意。）我从未在嵌入式 vfat 设备中看到任何功率损耗问题。不过，我在 WinCE 中遇到过 FAT 问题。但是，当我的“监视器”程序达到 100-200 个文件时，它拒绝创建更多文件。似乎 FAT 在根目录中有一个特殊的文件限制问题，在子目录中有一个稍大的问题。我需要能够在 1 个目录中创建 500-1000 个文件。所以 vfat 不行。

然后我切换到ext2。不过，我没有在启动时插入 fsck。（不知道我必须这样做。）一天之内，由于“inode something something”错误，我的“监视器”程序无法创建更多文件。灾难！

我当前的解决方案是 ext2 启动时带有“e2fsck -y”。到目前为止，它似乎很有希望。但是 e2fsck 和“启动时的 fsck”的整个概念一直困扰着我。e2fsck 本身占用了我的主要闪存和内存的 350kb 以上。（当它没有运行时。）这意味着它是我最大的程序。它比busybox还大。它几乎可以与我的内核相媲美。

我一直在考虑ext3。它记录了元数据，这不会造成伤害。不过，我怀疑它会有多大帮助。我认为应该用我的小文件和受控同步来覆盖我吗？它有一个有序的写入序列。这意味着数据也有一些日志记录。然而，这可能导致非确定性滞后。这在我的情况下很糟糕。（这可能不是问题。）它还具有预定同步功能。例如。每 5 秒提交一次。我认为这会干扰我自己的同步。过多的写入对 SD 卡不利。甚至工业的。我找不到有关如何禁用此功能的任何文档。而且 ext3仍然需要在每次启动时运行 fsck！但是 ext3 仍然是一种可能性。

分机 4。将修复ext3的很多性能问题。不过我真的不需要性能。而且我的发行版似乎没有内置的 mkfs.ext4 和 fsck.ext4。也许这不是问题。虽然可能。例如。e2progs-libs（依赖于 jfsutils）似乎有很多编译问题。

JFS、XFS、BRFSS。我的内核都支持。目前未包含在我的用户空间工具箱中。一切似乎都是相当庞大、复杂的系统。而且它们似乎都在启动时需要一个“fsck”等价物？

我也考虑过扔我自己的文件系统：总是写文件表的 2 个副本。遍历时，它选择具有正确 CRC 和最新序列号的那个。进行 2 阶段写入序列。分配临时，在提交时修复。不需要 fsck。恐怕这可能有点天真。

UPDATE3：顺便说一句，嵌入式系统（至少是这个）的本质是它们是自主的、无人值守的、遥不可及的，而且它们必须运行多年。像 fsck 这样可能需要人工交互的程序让我毛骨悚然。

Answer 1

你的故事有点不一致，或者至少是含糊不清：

我宁愿失去一切，也不愿面对“无法安装”、“等待 10 分钟 fsck”

暗示——尽管你实际上没有说出来——这是你实际遇到的问题。但是之后：

e2fsprogs-libs（对 jfsutils 的依赖）似乎在我的发行版中编译起来非常困难。

这意味着您根本没有任何 fsck，因为是提供的e2fsprogs-libs依赖项。因此，也许您仍处于规划阶段，甚至还没有使用例如 来测试系统，而是得出了应该从 JFS 开始的结论？这有什么特别的原因吗？e2fsprogse2fsckext4

我在树莓派交换（树莓派的主存储也是 SD 卡）上注意到，相当多的用户似乎对此类问题感到非常沮丧，尽管大多数人（包括我自己）从未遇到过这种问题。全部。起初我以为这些人不知道系统应该被彻底关闭这一事实，但在解释时这并不是一个难以理解的问题，而且即使系统已经正确关闭，也有人报告这一点。

你已经说过你需要这个能够容忍断电（这很公平），但我提到这一点是因为它意味着有一些pi，或一些 SD 卡，或两者的某种组合，很容易发生由于某些事件（电涌？）而损坏文件系统，这些事件在拔出插头或重新插入插头时定期发生。我也没有看到 - 并且有足够的时间让很多人尝试 -任何关于有人说他们已经切换到 btrfs 或 jfs 或其他什么的报告，现在问题已经解决了。

另一个神秘的事情是，即使人们拉扯电源线，这也不会经常导致文件系统无法使用。 当然，我已经用 pi 做过很多次了，用普通的 linux 盒子也做过数百次（电源被切断，系统变得反应迟钝，我筋疲力尽和生气等等）。虽然我见过轻微的数据丢失，但我从未见过文件系统在快速 fsck 后损坏到无法使用的程度。

再次，假设所有这些报告都是真实的（我不明白为什么很多人会对此撒谎），除了不彻底卸载之外还有更多的事情发生，但它似乎只影响一小部分用户，再次暗示某种常见的硬件缺陷。

在 pi 上，我在启动脚本中-y写入/forcefsck，以便在下次启动时自动运行并修复任何问题，无论这是否有必要。在 700 Mhz 单核上，对于包含约 4 GB 数据的 12 GB 文件系统，这需要约 10 秒的时间。所以“10 分钟”听起来像是一个非常长的时间，特别是因为您已经说过“这是用于写入的小型文件系统！”。

您也可以考虑sync定期打电话。

最后，你应该用你实际遇到的问题的更真实、更具体的细节来更新问题，而不是夸张。否则，它看起来太像一个不成熟的XY 问题，而拥有丰富经验和可能为您提供建议的人可能会很快跳过它。