☰

需要将 debian FS 只读可写层从 tmpfs 切换到 aufs，以免启动后丢失文件

tag-icon • tag-icon debian filesystems embedded tmpfs aufs
需要将 debian FS 只读可写层从 tmpfs 切换到 aufs，以免启动后丢失文件

我正在尝试在基于 Debian 9 的嵌入式系统上完成此操作。 root 的文件系统安装在 /etc/fstab 中：

# /etc/fstab: static file system information.
#
/dev/mmcblk1p1  /  ext4  noatime,errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

我当前的文件系统如下所示：

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

现在我需要做的是使用 unionfs（或 aufs）+ ext4 创建一个更具弹性的安装系统，因为 /ext4 可能会因断电而失败，并且可能会发生文件损坏。这里的想法是在底部有一个只读文件层，在顶部有一个可写文件层，用于 /home/debian 以及任何其他可能需要系统写入它们的文件（例如 var/log 目录）。我被告知，ext4 与嵌入式系统一起工作可能会定期意外断电，这会导致一系列磁盘问题/损坏，特别是因为我们将在应用程序运行时大量写入磁盘。（关联）。即使 ext4 中存在日记功能，这也完全正确吗？

经过几个小时的研究，我发现建议通过创建钩子/脚本等来浏览 /usr/share/initramfs-tools。创建新脚本并启动系统后，我得到了与我想要的类似的东西：

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /ro
root.rw         242M  8.5M  234M   4% /rw
root.union      242M  8.5M  234M   4% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

&& 使用 mount 我获得了新添加的 ro && rw 文件系统的以下详细信息：

/dev/mmcblk1p1  on  /ro                              type  ext4        (ro,relatime,data=ordered)
root.rw         on  /rw                              type  tmpfs       (rw,relatime)
root.union      on  /                                type  aufs        (rw,relatime,si=587d3414)

现在，这已经在制作位于 /ro 目录中的初始/只读系统方面发挥了作用，并且我已经在 /rw 中安装了可写层。这里的问题是，如果我创建新文件/目录，它们在启动设备后就会消失。深入研究这一点，我怀疑我使用 tmpfs 的事实可能导致了这个问题，因为它通常用于 RAM，但我很难在顶部使用 aufs (root.union) 来解决这个问题，但事实并非如此。

如何通过使 /rw 层保留启动后创建的任何新信息/文件来解决此问题？请记住，我的系统现在是只读的，因此每次我尝试进入脚本并将 /rw 安装为 aufs 时，它都会在启动设备后恢复回来。

注意：我当前的设置是否意味着当前应用程序的日志不会记录到我的 /var/log/... 并在启动设备后丢失？一些应用程序通常会登录到 /rw 目录中的 /var/log/syslog ，但我似乎无法确认它们是否在启动后保留新日志，或者只是恢复到启动时的日志？

答案1

AFAIK，ext4 的日志记录意味着实际损坏很少见，并且可以通过 fsck 修复。我从来没有遇到过任何 ext4 损坏，除了死盘（实际上拒绝在第二天旋转）。

Linux 的缓存意味着 RAM 充当具有后备存储的 tmpfs。如果您发现这太慢（这会令人惊讶，因为您使用的是闪存盘），您可以通过添加到 fstab 来增加刷新数据所需的时间commit=<time>，这会以速度损失数据为代价。

试图找到程序需要写入的内容是计算机科学中一个尚未解决的问题，其复杂性高于停止问题。为什么不将需要持久保存的内容存储在单独的分区/磁盘上，以便在出现故障时可以进行迁移？

相关内容