学习了,但还没有完全搞懂。
学习了

有个疑问,从这个描述来看似乎是用平时使用时时候的性能和空间占用换了备份还原性能。
那么问题来了,这个备份还原性能提升的代价是否划算呢?
就比如文中说的”自从 deepin-immutable-ctl 1.0.13.1 版本发布后,每次系统启动时,可能会出现将上层修改文件移动至下层修改层的情况。例如,上一次系统启动期间,系统监测到执行了软件包管理命令,该命令对 dpkg 状态数据库文件进行了改动。解决了单个部署中,同一路径的文件因多层存储导致多份存在、或者上层文件已删除但下层文件仍保留的情况所造成的空间浪费问题。后续会改成不依赖监控命令执行,也可自动触发。”,给我感觉好像每次操作系统都执行了一次
git add /.
git commit
git push
众所周知,当系统有大量小文件的时候git add.很消耗性能的
有个疑问,从这个描述来看似乎是用平时使用时时候的性能和空间占用换了备份还原性能。
那么问题来了,这个备份还原性能提升的代价是否划算呢?
就比如文中说的”自从 deepin-immutable-ctl 1.0.13.1 版本发布后,每次系统启动时,可能会出现将上层修改文件移动至下层修改层的情况。例如,上一次系统启动期间,系统监测到执行了软件包管理命令,该命令对 dpkg 状态数据库文件进行了改动。解决了单个部署中,同一路径的文件因多层存储导致多份存在、或者上层文件已删除但下层文件仍保留的情况所造成的空间浪费问题。后续会改成不依赖监控命令执行,也可自动触发。”,给我感觉好像每次操作系统都执行了一次
git add /.
git commit
git push
众所周知,当系统有大量小文件的时候git add.很消耗性能的
只有当修改层的大小达到一定阈值之后才会触发自动清理流程
总之,用过这磐石备份的空间会占用平常系统的两倍的空间。相当于系统本身一份,备份一份。而这系统备份对普通用户来说其实没什么重要意义。万一把系统搞崩了,普通用户重装的新系统更好,费了大精力还原的系统总会藏着多一些隐患。
总之,用过这磐石备份的空间会占用平常系统的两倍的空间。相当于系统本身一份,备份一份。而这系统备份对普通用户来说其实没什么重要意义。万一把系统搞崩了,普通用户重装的新系统更好,费了大精力还原的系统总会藏着多一些隐患。
说句实话,window奔溃之后,用他们提供的修复程序,我从来没成功过,都是重装。那么linux真的可以实现吗?磐石在看不到未来的情况下,还给正常的应用挖了个坑。
只有当修改层的大小达到一定阈值之后才会触发自动清理流程
这个阈值是多大呢?用户大概多久会触发一次?
总之,用过这磐石备份的空间会占用平常系统的两倍的空间。相当于系统本身一份,备份一份。而这系统备份对普通用户来说其实没什么重要意义。万一把系统搞崩了,普通用户重装的新系统更好,费了大精力还原的系统总会藏着多一些隐患。
所以单独挂载home分区,重装只重装系统盘,用户文件、配置还在,用户只需要重装软件就行了,为啥要搞那么复杂。
所以单独挂载home分区,重装只重装系统盘,用户文件、配置还在,用户只需要重装软件就行了,为啥要搞那么复杂。
实际上用户重要文件平常另备份到其他分区,常用配置自己熟悉,再配置文件也快。我对home不作特别处理。
实际上用户重要文件平常另备份到其他分区,常用配置自己熟悉,再配置文件也快。我对home不作特别处理。
这倒是,所以现在的不可变真的有那么大意义么,即使系统崩了,live进去拷贝文件出来也可以的。
甚至不如自带一个live的抢救模式。
学习了,但还没有完全搞懂。
眼睛会了,但是手不会。
什么时候我也可以
所以单独挂载home分区,重装只重装系统盘,用户文件、配置还在,用户只需要重装软件就行了,为啥要搞那么复杂。
我就是这么做的,方便的很。但如果能实现进系统后点点鼠标就能挂载HOME就太好了。类似windows里移动用户里的文件夹。

总之,用过这磐石备份的空间会占用平常系统的两倍的空间。相当于系统本身一份,备份一份。而这系统备份对普通用户来说其实没什么重要意义。万一把系统搞崩了,普通用户重装的新系统更好,费了大精力还原的系统总会藏着多一些隐患。
与传统的AB备份不同的时,磐石系统备份所占用的空间大小与修改层大小相关。如果修改层没有任何东西,那么备份系统不会占用额外空间,因为ostree仓库中已包含了所有文件
Popular Events
More

中文 
磐石系统结构
整体
一台电脑上磐石系统可以有多个系统部署,可以分别从GRUB菜单启动。
第一项规定为主线部署,第二项以及后面的项目都规定为备份部署。主线部署是给用户平时用的;备份部署是在主线部署功能出问题,像系统升级失败这种情况时,用来恢复到之前状态的。
使用如下命令查看部署情况:
输出内容类似:
这就表示当前有2个部署可以被启动,第一个部署(index: 0)有 * 标记,表示正在使用中。BaseCommitIdIdx对应系统部署ID,ExtCommitIdIdx对应数据部署ID。
想要了解更详细的信息,可以通过如下命令查看:
每个部署都共用 /var ,/var 实际位置在 /persistent/ostree/deploy/deepin/var 目录。
系统部署
每个系统部署是由 overlay FS 将系统层,数据层,修改层叠加而成。
部署的各层存储位置:
现在来简单介绍一下磐石系统用的 OSTree 技术。这个技术主要是用来管理操作系统文件还有它们的版本的,靠内容寻址存储和硬链接技术,能有效避免文件重复占存储空间。
传统的文件存储方式是依据路径和名称进行的,这种方式极易导致相同内容的文件被多次存储。与之不同的是,OSTree 采用哈希算法(例如 SHA256)为文件生成唯一的摘要(hash),相同内容属性的文件其哈希值是相同的。文件以哈希值作为标识,存储于共享对象存储区(通常为 /ostree/repo/objects/),从而避免了重复存储的问题。
当多个系统部署包含相同内容的文件时,OSTree 不会对文件进行复制操作,而是在部署目录(如 /ostree/deploy/...)为文件创建指向对象存储中对应哈希文件的硬链接。由于硬链接共享文件索引节点,多个部署的相同文件可以共用同一份物理数据,不会额外占用存储空间。
数据层与系统层文件从对应 ostree 仓库硬链接获取,仅目录占少量空间,文件与仓库共享。系统层和数据层有提交(commit),可消除重复文件。
磐石系统的快照大部分存在系统层和数据层 ostree 仓库中,其中快照分支名称以“snapshot/”为前缀,小部分文件(/var 部分)存储在 /persistent/ostree/snapshot/$快照ID/ 中,这部分占用一般比较小。
因此,若需粗略地计算磐石系统(不含家目录)全部部署所占用的空间,需将如下:
这几个路径下的所有占用空间进行相加。
修改层
磐石系统采用双修改层机制,通过硬链接下修改层文件实现零冗余存储,提升快照与备份性能。
详细查看修改层占用可以使用如下命令:
输出类似:
修改层文件移动机制
自从 deepin-immutable-ctl 1.0.13.1 版本发布后,每次系统启动时,可能会出现将上层修改文件移动至下层修改层的情况。例如,上一次系统启动期间,系统监测到执行了软件包管理命令,该命令对 dpkg 状态数据库文件进行了改动。解决了单个部署中,同一路径的文件因多层存储导致多份存在、或者上层文件已删除但下层文件仍保留的情况所造成的空间浪费问题。后续会改成不依赖监控命令执行,也可自动触发。
欢迎大家在留言区分享自己的使用情况或想法 📣