ext3 文件系统使用什么挂载选项来最大程度地减少数据丢失或损坏？

Question

我有一个嵌入式设置，使用 initramfs 作为根文件系统，但使用安装在紧凑型闪存 IDE 驱动器上的自定义 ext3 分区。因为面对断电时的数据完整性是整个设置中最重要的因素，所以我使用了以下选项进行挂载（以下是我的/etc/fstab文件中的条目

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

我通过在互联网上阅读这些选项获得了这些选项。我担心的是，/proc/mounts给出以下内容：

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

我从阅读中了解到，我想data=journal为我的挂载使用选项，因为这提供了最好的数据损坏保护。但是，从特定 ext3 选项的手册页中，mount它对写回选项进行了以下说明：

不保留数据排序 - 数据可能会在其元数据提交到日志后写入主文件系统。
据传这是最高吞吐量的选择。它保证内部文件系统的完整性，但是它可以允许旧数据在崩溃和日志恢复后出现在文件中。

我对此感到非常困惑 - 手册页似乎表明为了文件系统完整性，我想指定data=writeback选项，mount但我发现的大多数其他参考文献（包括一些关于嵌入式 linux 的已出版书籍）建议我应该使用data=journal. 我使用的最佳方法是什么？写入速度根本不是问题——数据完整性才是问题。

Answer 1

不要被仅writeback提及的事实误导internal filesystem integrity。
随着ext3，无论你用journal，ordered或者writeback，文件系统元数据总是轴颈，这就意味着内部文件系统的完整性。

该数据模式提供的控制权如何的方式普通数据被写入到文件系统。
在writeback模式下，元数据更改首先记录在日志中并写入提交块。日志更新后，元数据和数据写出可以继续进行。 data=writeback 可能是一个严重的安全风险：如果系统在附加到文件时崩溃，在元数据提交之后（并分配了额外的数据块），但在数据写入之前（数据块被新数据覆盖），然后在日志之后恢复该文件可能包含填充有来自以前删除的文件的数据的块 - 来自任何用户¹。

因此，如果数据完整性是您的主要关注点，而速度并不重要，data=journal那么这就是您要走的路。

Answer 2

正如您已经注意到的，要点是您无法防止文件系统发生各种崩溃。

你可以做什么：

1. 在软件方面，您可以在每次重要操作后使用fdatawrites（请参阅Theodore T'so 的2003 年帖子，主要 Linux FS 内核开发人员。它仍然是正确的。还有一个关于隐藏在旧版本 ext4 中的主要数据丢失的帖子）
2. 将提交间隔减少到 1 秒（commit=1）（请参阅LWN 的这篇文章，它是关于 ext4 但包含有关 ext3 的非常有用的信息）。注意：它不应该是需要的，使用sync。
3. 正如 sim 指出的 RHEL 文档所说，使用 *data_err=abort* 和data=ordered
4. noatime将减少对文件系统的无用操作
5. 正如您已经注意到的，barrier=1是减少数据丢失的好方法（请参阅此帖子）
6. 而同步也是，当然是“我不想失去我的数据”选项之一。

最后，偏执的安装选项可能如下所示：

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

您还可以在每次启动时通过自动 fsck 确保数据完整性。