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

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安装一个挂载-t命令。选项"noatime“而不是"sync”。我的发行版是一个定制的模拟设备风味的uClinux，带有一个3.10内核和一个1.21busybox。我的主要存储是带有jffs2的spi闪存。我从来没有对此有过任何意见。我甚至不知道是否有可用的fsck.jffs2。另一方面闪光灯..。但那是另一个故事。SD卡的目的是存储测量数据。“监视器”程序将结果附加到文件中，并具有战略同步位置。当文件超过给定大小时，将创建新文件。当达到给定数量的文件时，最老的文件将被删除。如果当前的测量文件因功率损失而丢失，则不会造成灾难。文件通常在50-100 1kb，一个结果通常是1kb。这只是最初的开发阶段。没有什么是固定的。这是我第一次在嵌入式系统中处理非flash文件系统。(我在我的ext4服务器上找到了x86。)

我从凡夫特开始。默认的文件系统。)我想这些工厂可能有理由选择它。如果事情成功了，我也不会那么在意。)我从来没有见过在我的嵌入式vfat设备中出现任何断电问题。不过，我在WinCE中经历过脂肪的问题。然而，当我的“监视器”程序达到100-200个文件时，它拒绝再创建任何文件。看起来FAT在根中有一个特殊的文件限制问题，在子目录中有一个稍微大一些的问题。我需要能够创建500-1000个文件在1迪尔。所以vfat做不到。

然后我转到ext2。不过，我在创业时没有插入fsck。(不知道我必须这么做。)一天之内，我的“监视器”程序由于“inode某某物”错误而无法创建更多的文件。灾难！

我目前的解决方案是ext2，在启动时有一个"e2fsck -y“。到目前为止似乎很有希望。但e2fsck和整个“初创公司fsck”的概念都在困扰着我。e2fsck本身正在花费超过350 my的我的主要闪光灯和内存。(当它不运行的时候)这意味着这是我最大的节目。它比百事箱还大。它几乎和我的内核相提并论。

我一直在考虑ext3。它已经记录了元数据，这不会有什么影响。不过，我怀疑这会有多大帮助。用我的小文件和控制的同步，我想我应该被覆盖？它有一个有序的写入序列。这意味着数据也会在某种程度上被记录。然而，这可能导致不确定的滞后。这在我的情况下是不好的。(这可能不是问题。)它还具有计划的同步功能。例如：每5秒提交一次。这干扰了我自己的同步。写太多的东西对SD卡不好。甚至是工业的。我找不到任何关于如何禁用它的文档。而且ext3仍然要求fsck在每一家创业公司都能运行！但ext3仍然是一种可能性。

Ext4。将修复ext3的许多性能问题。不过，我不需要表演。而且我的发行版似乎没有内置的mkfs.ext4和fsck.ext4。也许这不是个问题。可能是吧。例如：E2progs-lib(依赖于jfsutils)似乎存在很多编译问题。

JFS，XFS，BRFSS。都是由我的内核支持的。目前未包括在我的用户空间工具箱中。所有这些似乎都是相当大、复杂的系统。他们在创业时似乎都需要一个“fsck”等价物？

我还考虑过抛出自己的文件系统:始终编写文件表的两个副本。遍历时，选择具有正确CRC和最新序列号的一个。制作一个两阶段的写入序列.临时分配，在提交时修正。不需要fsck。我担心这可能有点天真。

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

Answer 1

在你的故事里，有一点不一致，或者至少是模棱两可：

我还是宁愿失去一切，也不愿面对“无法上马”、“等这10分钟fsck”

这意味着--尽管你并没有说出来--这是一个你正在经历的问题。但随后：

e2fsprogs-libs (依赖jfsutils)似乎很难在我的发行版中编译。

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

我在raspberry pi交换(pi的主要存储也是SD卡)上注意到，相当多的用户似乎对这类问题感到非常沮丧，尽管大多数用户(包括我自己)根本就没有这样的问题。起初，我以为这些人都不知道系统应该被彻底关闭，但在解释的时候，这并不是一个很难理解的问题，有些人报告说，即使系统已经被正确关闭了。

您已经说过您需要这样才能容忍断电(这很公平)，但是我提到这一点，因为它意味着有一些pis，或者一些SD卡，或者两者的结合，它们只是因为某些事件(激增？)而容易损坏文件系统。无论是拔掉插头，还是重新放回插头时，都会有规律的发生。我也没有看到--而且有足够的时间让很多人去尝试--有报道说有人说他们转向了btrfs或jfs或者其他什么，现在这个问题已经解决了。

另一个神秘的事情是，即使有人拉绳，这不应该经常导致一个不可用的文件系统。当然，我已经做了很多次w/ pi，如果不是几百次的话，一个普通的linux盒(电源被切断，系统变得没有响应，我精疲力竭，愤怒等等)。虽然我看到了少量的数据丢失，但我从未见过一个文件系统被损坏到在快速fsck之后无法使用的地步。

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

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

您还可以考虑定期调用sync。

最后，你应该用你实际遇到的问题的更真实的、具体的细节来更新这个问题，少夸张一些。否则，它看起来就像一个不成熟的XY问题，它可能会很快被那些有丰富经验和潜在建议的人所忽略。