最近，我们的客户遇到了一个相当不愉快的情况 - 用于显示遥感数据的基于 Raspberry Pi 的“信息亭”（没有什么比显示来自数据收集服务器的自更新网页的信息亭模式浏览器更花哨的了）由于以下原因无法启动文件系统损坏。Ext4，需要手动fsck，系统将成为明天重要演示的一部分，立即需要服务。当然，我们不能要求客户在晚上关闭系统时很好地关闭系统；该系统必须简单地承受这种虐待。
我想在未来避免这种情况，并且我想将操作系统移动到一个可以防止这种情况的文件系统。有很多用于 MTD 设备的文件系统，让它们在 SD 卡（标准块设备）上运行需要一些严重的跳跃。还有一些其他文件系统（日志等）具有良好的抗腐败能力。我仍然需要看到他们的优缺点的一些合理比较。
Linux 中可用的哪个文件系统将在意外电源故障时提供最佳的抗破坏性，并且不需要跳过像yaffs2这样不可能的箍来安装到 SD。
磨损平衡是一个优点，但不是必需的——SD 卡通常有自己的机制，如果不够完美，尽管系统应该是“对闪存温和的”（像 NTFS 这样的系统可以在一个月内杀死 SD 卡）。
我在同一个分区 (EXT2) 上有两个文件夹 如果我mv folder1/file folder2和某些中断发生（例如电源故障），文件系统最终会不一致吗？
mv操作不是原子的吗？
更新： 到目前为止，在 IRC 上我得到了以下观点：
有人可以澄清吗？
正如ZFS 专门声明的那样，ZFS 声称是无懈可击的 ZFS 承认它可能容易受到电源故障的影响。
我找不到 BTRFS 这样的声明。它（或设计/计划）在停电期间耐用吗？
似乎在严重崩溃中，尤其是 UPS 无法保持系统运行时，日志的某些内容会由于文件系统缓存而丢失。作为实验，我尝试使用同步选项挂载 /var 分区。启动时有更多的磁盘噪音，但显示停止器试图运行 apt。磁盘砰的一声响起，而 apt 坐在那里没有反应。
挂载 /var sync 是错误，还是成功所需的选项之一，例如 relatime、strictatime 或 noatime？如果是这样，在 /var 上使用这些选项之一是否安全？
我的问题类似于这个线程LVM 会增加数据丢失的风险吗？但是，我找不到满意的答案。
所以问题是，当我有 3 个物理磁盘的卷组 (VG) 时，LVM 在哪里存储数据/文件？当一个磁盘出现故障时会发生什么？我可以拔掉那个磁盘，告诉 LVM 从 VG 中删除那个物理磁盘，然后继续使用其他磁盘吗？所以真正的问题是：LVM 是将文件保存在一个磁盘上，还是 LVM 将文件分段并将其拆分到三个磁盘上？第一个选项不可能是正确的，因为当我有一个 3GB 的文件时会发生什么，我的 VG 说 3GB 是免费的，但实际上每个磁盘只剩下 1GB 的空间。那么后者是真的吗？但这意味着我肯定会丢失除故障磁盘以外的其他一些数据？
在 Linux 的mount(2)手册页中，我注意到以下摘录：
许多损坏的应用程序在通过模式替换现有文件时不使用 fsync()，例如
Run Code Online (Sandbox Code Playgroud)fd = open("foo.new")/write(fd,...)/close(fd)/ rename("foo.new", "foo")或者更糟
Run Code Online (Sandbox Code Playgroud)fd = open("foo", O_TRUNC)/write(fd,...)/close(fd).如果启用了 auto_da_alloc，ext4 将检测替换通过重命名和替换通过截断模式并强制分配任何延迟分配块，以便在下一次日志提交时，在默认的 data=ordered 模式下，在提交 rename() 操作之前，新文件被强制写入磁盘。这提供了与 ext3 大致相同级别的保证，并避免了在延迟分配块被强制写入磁盘之前系统崩溃时可能发生的“零长度”问题。
这段代码在什么意义上被“破坏”了？他们是说这段代码是非法的还是不符合标准（POSIX 等）？
显然fsync()，对于担心系统崩溃会发生什么的人来说，这可能是一个好主意。但是假设系统不会崩溃，那么示例代码的两个版本（没有fsync()）是否都做正确的事情？