我有一个嵌入式设置,使用 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
.我使用的最佳方法是什么?写入速度根本不是问题——数据完整性才是问题。
答案1
不要被仅writeback
提及的事实所误导internal filesystem integrity
。
无论ext3
您使用journal
或ordered
,writeback
文件系统元数据始终是日记式的这意味着内部文件系统的完整性。
这数据模式提供一种控制方式普通的数据写入文件系统。
在writeback
模式下,元数据更改首先记录在日志中,并写入提交块。日志更新后,可以继续进行元数据和数据写出。 data=writeback
可能会造成严重的安全风险:如果系统在追加到文件时崩溃,则在提交元数据(并分配其他数据块)之后,但在写入数据之前(用新数据覆盖数据块),然后在日志之后恢复该文件可能包含填充了以前删除的文件中的数据的块 - 来自任何用户1。
因此,如果数据完整性是您主要关心的问题并且速度并不重要,那么data=journal
这是正确的选择。
答案2
正如您已经注意到的,要点是您无法防止文件系统发生各种崩溃。
你可以做什么:
- 在软件方面,您可以使用数据写入每次重要操作后(参见这篇2003年的帖子来自 Linux FS 内核主要开发人员 Theodore T'so。这仍然是事实。还有这个关于旧版本 ext4 中隐藏的重大数据丢失)
- 将提交间隔减少到 1 秒(提交=1) (看本文来自 LWN,它是关于 ext4 的,但包含有关 ext3 的非常有用的信息)。注意:不需要,因为同步。
- 正如 sim 指出的 RHEL 文档所说,使用 *data_err=abort* 和数据=已排序
- 诺阿泰姆将减少文件系统上的无用操作
- 正如您已经注意到的,屏障=1是最小化数据丢失的好方法(请参阅这个帖子)
- 和同步当然,这也是“我不想丢失我的数据”选项之一。
最后,偏执的安装选项可能如下所示:
auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,
您还可以在每次启动时通过自动 fsck 确保数据完整性。
答案3
尝试更改您强调的手册页的哪一部分:
回写
不保留数据顺序- 在将数据的元数据提交到日志后,数据可以写入主文件系统。据传这是吞吐量最高的选项。它保证内部文件系统的完整性,但是,它可以允许旧数据在崩溃和日志恢复后出现在文件中。
正如 don_crissti 指出的那样,其他模式没有“但是”。