Reviewed-on: #5
5.6 KiB
title, tags, date
| title | tags | date | ||
|---|---|---|---|---|
| 日用Linux挑战 第4篇 新的开始 |
|
2024/03/09 14:00:00 |
小步快跑,面向未来。
在上一次更新“日用Linux挑战”之后的六个月时间中,我又重新在我的两台电脑上安装了ArchLinux。在这一轮新的系统安装中引入了不少令人激动的新技术。
BTRFS
在所有的新技术中最激动人心便是新的文件系统Btrfs,作为“面向Linux的现代写时复制文件系统”,Btrfs致力于在实现高级特性的同时保证对错误的宽容和使用与维护的便利性。
相较于古老但是稳定的Ext4文件系统,Btrfs对我来说最大的好处便是可以零成本的创建快照,便于在出现错误的时候及时回滚或者直接重装系统。因此,为了方便快照的生成和回滚,我在安装系统时使用扁平化的子分区划分方法:即尽力避免出现嵌套的子分区,所有需要快照的分区都处在/目录之下:
@为根分区,挂载在/目录之下,打开写时复制;@home为家目录分区,挂载在/home目录之下,打开写时复制;@swap为交换分区;@var挂载在/var目录之下,鉴于这下面的文件大多数为生成的数据文件,关闭写时复制;@snapshots是存储快照的子分区,挂载在/.snapshots目录之下,打开写时复制。
在一般情况下上每天对@home分区进行快照,存放在/.snapshots目录下,每周将当天备份的数据备份到移动硬盘中。
使用BTRFS的一些小提示
由于docker使用的默认文件系统是overlay2文件系统,也是一个支持写时复制的文件系统,而在写时复制文件系统BTRFS上再叠一层写时复制文件系统显然不好,而且docker官方也提供了对于btrfs文件系统的支持,因此需要修改docker使用的文件系统,按照官方文档操作即可。
对于一些常常修改的文件夹例如.cache,可以关闭写时复制。
在通过SSH将数据备份到远程服务器时,可以使用zstd压缩之后再发送,可以大幅减少需要传送的数据量:
sudo btrfs send /.snapshots/home@20240225 | zstd | ssh root@remote "zstd -d | btrfs receive /path-to-backup"
Wayland
算起来,我已经和Wayland显示协议相爱相杀了整整一年了,从KDE plasma X到Hyprland,再尝试小众的labwc,最后回到了KDE plasma X。而在2024年2月29日KDE plasma释出6.0版本,将Wayland作为默认的显示协议,我也在第一时间更新了版本并使用wayland显示协议。现在,我可以比较确定的说,Wayland目前已经达到可用的水平了,而且我还是使用RTX 3060显卡。
不过相较于AMDGPU可以开箱即用,使用NVIDIA启动需要配置如下的模块参数:
options nvidia_drm modeset=1 fbdev=1
同时NVIDIA驱动的版本在550以上。如果NVIDIA驱动的版本< 550,那么就需要在内核参数中配置nvidia_drm.modeset=1,因为在之前的NVIDIA版本驱动中对于simpledrm的支持还不完善,需要通过内核参数禁用,而且这是一个。ArchLinux提供的hack
对于输入法,在使用fcitx5输入法并通过Virutal Keyboard启动输入法之后,在几乎所有的Wayland应用程序中都能够正常的唤起输入法,包括各种基于chromium的浏览器和Electron应用,不过需要在启动应用时传递如下的参数:
--enable-features=UseOzonePlatform
--ozone-platform=wayland
--enable-wayland-ime
不过XWayland应用程序在使用NVIDIA驱动时会存在一个神奇的同步失败问题,表现为在xwayland中部分控件闪烁,交替显示更新前和更新后的帧,而且这个问题几乎不能被截屏抓到,具体可以见freedesktop上的这个issue。虽然这个议题下面有着很长的讨论,还是建议大家完整的看一遍,里面甚至还有:
省流:这个议题讨论了在xserver中提供显式同步的协议原语,方便图形驱动程序知道什么时候渲染的帧发生了变化。因此这并不是一个NVIDIA驱动程序的问题,而是需要将Linux显示协议栈从隐式同步迁移到显式同步。但是相关的工作还在开发过程中,因此解决方法有两个:
- 避免使用
xwayland应用; - 自行编译该合并请求!967,或者使用这个xorg-xwayland-explicit-sync-git。
安装双系统获得的新知识
在这轮安装过程中,为了保证在极端情况下的可用性,我都是选择了双系统Windows和ArchLinux进行安装。但是这也带来了一个问题:Windows安装的过程中创建的EFI分区只有100M的空间,而现在Linux内核的大小一般是14M左右,而initramfs的大小来到了24M上下,再加上一个更大的备用initramfs,装不下,怎么想也装不下,分分钟撑爆/boot分区。
于是,我就在Arch Wiki上学到一条新知识:
原来efi分区其实只用放grub,,,




