你确定这部分是开源的吗？

我想看源码的原因很简单，因为我在deepin官网上得到这样的描述：

全盘安装的好处是，默认会分配A/B区间，也就是系统的镜像空间，这就提供了通过控制中心更新后可以进行回退的功能，使用系统回退功能的前提：
采用全盘安装；
安装的时候有选择“创建初始化备份”
更新时通过控制中心更新，而非终端更新；
具备系统回退能力的设备，在每次系统更新后，可以在grub界面回退到上一版本。

https://www.deepin.org/zh/deepin-25-installation

其中，

使用系统回退功能的前提：
采用全盘安装；

让我感到好奇。

我无法全盘安装，于是我手动分区安装的。

然后，我猜想，我无法使用系统回退功能，那么磐石会以什么样子工作呢？

然后，我的分区是：

ESP 2G

/ 100G

我查看了/etc/fstab 根分区没有挂载为只读，当然，在桌面也是可以创建文件的。

但是，在/usr/bin无法创建文件，我尝试了touch echo python的open

它提示：只读文件系统

这就很神奇了，我想看看背后是什么技术实现的。

虽然，有很多种技术来实现，但是，我想知道是哪一种，而不是猜。

假设不开源，是出于什么原因？

防 友商？

既然是统信，那就合理了。

看来磐石和deepin没什么关系，是统信要加。

希望他们能把这玩意搞好。

咳咳，我了解磐石的工作原理了，这有助于帮助我们理解。

可以使用

mount | grep "ro"

看看挂载点。

会得到如下输出：

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
usr-overlay on /usr type overlay (ro,relatime,lowerdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/usr-upper:/root/persistent/ostree/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/checkout/usr:/root/ostree/deploy/deepin/deploy/d1837b42d34f727ce259ba571c87e05bf21dcd389c07f5d0f2a63ceaa34579fc.1/usr,upperdir=/root/persistent/overlay/data/layer-984aa8ffcffe3f7f/usr,workdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/usr-work,uuid=on)
opt-overlay on /opt type overlay (rw,relatime,lowerdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/opt-upper:/root/persistent/ostree/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/checkout/opt:/root/ostree/deploy/deepin/deploy/d1837b42d34f727ce259ba571c87e05bf21dcd389c07f5d0f2a63ceaa34579fc.1/opt,upperdir=/root/persistent/overlay/data/layer-984aa8ffcffe3f7f/opt,workdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/opt-work,uuid=on)
etc-overlay on /etc type overlay (rw,relatime,lowerdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/etc-upper:/root/persistent/ostree/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/checkout/etc:/root/ostree/deploy/deepin/deploy/d1837b42d34f727ce259ba571c87e05bf21dcd389c07f5d0f2a63ceaa34579fc.1/etc,upperdir=/root/persistent/overlay/data/layer-984aa8ffcffe3f7f/etc,workdir=/root/persistent/overlay/data/ba18356ff2537bc4c1df6ee7aca3391ce982edb8825c68de1c9c72b69cfb36a6.0/etc-work,uuid=on)
/dev/nvme0n1p1 on /sysroot type ext4 (rw,relatime)
/dev/nvme0n1p1 on /sysroot/ostree type ext4 (ro,relatime)
/dev/nvme0n1p1 on /ostree type ext4 (ro,relatime)
/dev/nvme0n1p1 on /persistent/ostree type ext4 (ro,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13071)
/dev/nvme0n1p2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
/dev/sda4 on /media/likewendy/b223823b-13d9-4e29-986e-3f840a05a58f type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,stripe=8191,uhelper=udisks2)
/dev/sda2 on /media/likewendy/VTOYEFI type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/nvme0n1p5 on /media/likewendy/c5b68963-7f31-453f-8a33-11d45badf8cc type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)
/dev/sda1 on /media/likewendy/Ventoy type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,iocharset=utf8,errors=remount-ro,uhelper=udisks2)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

这比较乱，但是可以看到有：

usr-overlay on /usr type overlay (ro,relatime,lowerdir=...,upperdir=...,workdir=...)
opt-overlay on /opt type overlay (rw,relatime,...)
etc-overlay on /etc type overlay (rw,relatime,...)

这是由linux内核提供支持的OverlayFS特性。

这里引用DeepSeek的解释：

1. OverlayFS（内核支持）

• 内核模块：OverlayFS是一种内核文件系统驱动程序，自Linux内核3.18版本开始被合并到主线内核中。因此，它的核心功能由内核直接提供。
• 功能：它允许将多个目录（称为层）合并成一个单一的视图。通常包括：
  • lowerdir：一个或多个只读的底层目录（可以理解为基础镜像）。
  • upperdir：一个可写层（用于存储修改）。
  • workdir：一个用于文件操作（如创建、重命名）的工作目录，必须是和upperdir在同一个文件系统上的空目录。
• 挂载选项：通过 mount命令或 /etc/fstab挂载时，可以指定 ro（只读）或 rw（读写）选项。当挂载为只读时，即使有 upperdir，也不会允许写入。

另一个东西是OSTree，在Fedora中也有用到，主要用于原子更新、系统回滚。

这是一个用户空间的服务。

2. OSTree（用户空间服务）

• 用户空间工具：OSTree是一个命令行工具和库（用C语言编写，但提供C和Python API），它运行在用户空间。它由多个组件构成：
  • ostree命令行工具：用于系统管理（如 ostree admin deploy部署新版本，ostree admin status查看状态等）。
  • libostree库：提供核心功能，如处理仓库、提交、检出等。
• 工作原理：
  • OSTree利用文件系统的特性（如硬链接）来高效地存储多个版本的系统文件（避免重复占用空间）。
  • 在部署时，它将基础系统文件（来自OSTree仓库）检出一个只读的目录树（例如 /ostree/deploy/$os/deploy/$commit）。
  • 然后，它通过OverlayFS（或绑定挂载）将只读层与用户可写层（如 /etc和 /var的修改）合并，形成系统运行时视图。
• 与系统启动集成：OSTree通常与initramfs（初始内存文件系统）和引导加载程序（如GRUB）集成。在启动过程中，initramfs中的脚本（或systemd单元）会设置OverlayFS挂载，将只读的系统目录和可写目录合并挂载到目标位置（如 /usr、/etc等）。

为什么需要重启，有两个可能的原因，一个是 /usr 等目录被关键进程（如 systemd、glibc）占用，无法热重载。

另一个是OSTree：

OSTree 在部署新系统版本时，会创建全新的只读目录（如 /ostree/deploy/deepin/deploy/）

切换版本必须重启，以卸载旧目录并挂载新目录。

我感觉，这个东西应该真的只是为了“系统别崩”，特别是OverlayFS。这可能是磐石的核心。

这个东西吧，要说不能修改，也不完全是，似乎直接改OverlayFS只读挂载的源目录就可以了，但问题是源目录是OSTree里面的目录，这会破坏OSTree的校验和（commit ID是基于内容计算的），说不定什么时候系统就起不来了。

但是吧，说不定能修改OverlayFS 的 upperdir实现篡改文件。

所以，它不太可能是为了防止恶意软件，更多的是“系统别崩”。

当前人们还是需要写入只读的目录，什么时候不需要写入了，就不会出现虽然有这个功能，但是没法用的尴尬局面了。不过，能够写入这些目录的东西，有没有可能把系统搞坏？比如安装了一个应用商店的包就把文件写坏了。这可能是需要解决的问题。

有个好处可能是把锅分开了，操作系统不用无辜背锅了，什么破软件把系统文件写坏了，再怪操作系统。而开启磐石的人，操作系统坏了，还真得怪系统。

我不知道这些分析有几分正确几分错误，但是，了解实现原理有助于更好的使用，不犯低级错误。

再好的系统，也怕人的低级错误。

总的来说，它用了两个东西，一个是内核里面的OverlayFS，这个东西非常容易理解：把目录挂载到目录。

另一个是OSTree，用于操作系统升级的时候原子更新、回滚。

我原以为是创建了一个分区，作为只读，看来不是，把目录挂载到目录更有兼容性。