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

关于这个问题有几个现有的话题，但是我所寻求的略有不同。我在嵌入式Linux上有SD卡，它会掉电。我也许可以在某个时候修改硬件，正确关闭硬件等等，但是等等，但是现在，我只是想找到一个在断电后仍能正常工作的文件系统。数据丢失是可以接受的。我宁愿不丢失比当前正在写的文件更多的信息，但我还是宁愿丢失所有文件，也不愿面对“无法装载”，“等待10分钟fsck”或“无法创建新文件”。文件由于此inode出现了一些错误”。该程序必须继续！

为了确保这一点，我正在付出很多努力。我使用的是工业级组件，有硬件看门狗，软件看门狗，内部，外部，用于重新启动程序的init，不断检查内存，文件描述符的守护程序等等，我有看门狗看我的看门狗，而这些看门狗又会监视其他看门狗...但是我似乎无法保证SD卡能够安装并正常运行？

目前，我最好的选择是在SD卡上使用JFS，在我的安装中包括fsck和fsck.jfs。（添加600kb +占用了我的ram和flash。这是不好的。）并在每次启动时运行fsck（可能会增加很多启动时间。这有些不好。）。不过似乎有点难过。

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

更新：e2fsprogs-libs（对jfsutils的依赖）在我的发行版中似乎很难编译。我将研究ZFS（不过，它并不是我的发行版中的本机。它似乎做了很多我不需要的事情。）

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

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

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

我当前的解决方案是在启动时使用“ e2fsck -y”的ext2。到目前为止，这似乎很有希望。但是e2fsck和“启动时fsck”的整个概念困扰着我。e2fsck本身就花费了超过350kb的主闪存和ram。（当它不运行时。）这意味着这是我最大的程序。它比busybox大。它几乎可以与我的内核媲美。

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

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

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

我还考虑过抛出自己的文件系统：始终写入文件表的2个副本。遍历时，它将选择具有正确CRC和最新序列号的一个。进行两个阶段的写入序列。临时分配，修复提交。无需fsck。恐怕这可能会有些天真。

UPDATE3：顺便说一句，嵌入式系统（至少是嵌入式系统）的本质是它们是自治的，无人看管的，遥不可及的，并且它们必须运行多年。诸如fsck之类的程序可能需要人与人之间的交流，使我无所适从。

在您的故事中，这里有些矛盾或至少是含糊之处：

我还是宁愿丢掉这一切，也不愿面对“无法挂载”，“等待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问题，有很多经验和潜在建议的人可能会很快跳过它。

该程序必须继续！

好吧，这是一个普遍的要求，而Linux系统是选择稳定系统的最佳选择。

您的努力似乎也没有朝着正确的方向发展。但是，如何才能获得稳定的系统？

在第一级，您可以改善文件系统：

• 使用yournal_data_ordered在ext3/ext4创建或修改与文件系统时，tune2fs。
• 配合检查时JFS使用--replay_journal_only。
• 通过FSCKFIX=yes在启动脚本中进行设置来启用自动修复。

如果这还不够，您可以在不装入错误磁盘的情况下引导系统。而是ramdisk在手动检查和修复错误的磁盘时创建一个全新的磁盘。这也可以通过脚本自动执行。

在下一级别中，您需要离开嵌入式系统，并阅读有关高可用性的一些主题