依云's Blog

序

最近一段时间，不知道是磁盘、缓存相关算法的更新，还是我开的服务太多，又或者是新软件占用内存太高，我的系统越来越卡了，尤其是更新系统的时候（备份系统时也特别卡，然后我用限制内存占用的办法解决了）。我当然知道最主要的原因是因为机械硬盘的处理能力就那么多，于是经过一些了解和计划之后，还是决定换 SSD 了。

刚才查看了一下历史数据。从去年七八月份起，平均内存使用量从2G多升高到了3G多。大概是火狐更占内存了吧。我都尽量减少内容进程数量了……也可能是 PHP / MediaWiki 的锅，因为使用 SQLite 存储时，经常发生错误也是这段时间的事情。不过也可以理解为由于磁盘负载重导致的。算了不管了。

准备工作

当然首先要去买块 SSD 啦。我买的是 LITEON T11 Plus 512，512GB，800块。实际操作系统得到的空间是 477GiB，因为硬盘产业还在沿用1000进制的单位词头。它比我预期的要小不少呢，不过拿在手里感觉比一般同样大小的电路板要重。

拆开我的 T470p，把空闲接口旁边的螺丝下下来，然后 SSD 标签朝外插进去。我也不清楚这个接口叫什么。插进去之后它是翘起来的，难怪要用螺丝固定。然后用下下来的螺丝固定好，再把机器装好，就好了。启动系统，可以看到 /dev/nvme0n1 设备在了～GNOME 磁盘软件不能读取到 SMART 信息，用 smartctl -a /dev/nvme0n1 命令就好了。

设备没问题了，接下来当然是备份系统啦。

开始迁移

备份妥当之后，我就开始格式化 SSD。计划是 EFI 分区 512M，400G 给我的 Arch Linux，然后剩下 76G 左右的空间预留给我的 Win10。

然后这 400G，首先上一层 LUKS 加密，然后格式化为 btrfs 文件系统。其实我想要 btrfs 很久了，快照、去重、压缩都挺棒的。但是听说它的性能比较差，而我已经在受磁盘 I/O 能力不足的苦了，所以到现在有了 SSD，是时候换 btrfs 了！

其实之前 zfs（zfsonlinux）也是候选项，并且已经在工作本上使用过了。然而最近我的 zfs 备份两度出现问题（磁盘掉线之后 zfs 元数据损坏，导致一整个 zfs 文件系统一写就卡住；近期莫名其妙 rsync 跑着跑着就卡在那里不动了，磁盘也没有什么活动），再加上之前遇到的各种大小问题（ARC 被算进内存使用量中；挂载期间一旦磁盘离线就卡死；克隆出来的文件系统无法摆脱原文件系统；不支持 overlayfs；因为是树外模块所以需要专门准备的支持 zfs 的系统来执行安装），以及 TRIM 支持刚刚才加入，我已经停用 zfs 并将其排除考虑范围了。

然后就是规划子卷。参考了 openSUSE 的方案，最终决定分为这么几个子卷：/, /var/cache, /var/tmp, /var/log, /var/lib/lxc/lxc-debian/rootfs, /var/lib/lxc/lxc-centos6/rootfs, /home/lilydjwg, /home/lilydjwg/.cache。主要考虑的是快照。另外我给 /var/log/journal 和 /var/lib/postgres chattr +C 禁用了 CoW。这样也会禁用压缩，不过本来它们基本上就没什么可压缩的。需要排除的有：我的公开第三方源码和各类大文件用的 /ldata 还是放在机械硬盘上、/var/cache/pacman/pkg 缓存不要、/var/lib/pacman.fs 不用单独放连续的文件里了、/home/lilydjwg/.cache 缓存不要、/home/lilydjwg/.debug 这个 perf top 用的目录会有 libc 的硬链接，rsync 时会失败所以就不要了。

最终的同步命令如下：

sudo systemd-run -p MemoryMax=64M --scope \
  rsync -aviHAXKhPS --inplace --delete --exclude='*~' --one-file-system \
  / /mnt/root --exclude=/var/cache/pacman/pkg --exclude=/home/lilydjwg/.cache \
  --exclude=/var/lib/pacman.fs --exclude=/ldata --exclude=/home/lilydjwg/.debug

同步好之后，重启进入 live 系统再同步一次以保证最新数据也同步好了。然后把部分被排除的目录再同步一下：~/.cache/winetricks 这个以后不一定能够下到、~/.cache/sxiv 都是有效缓存（我有清理）而且生成耗 CPU、/var/lib/pacman 这个是被 --one-file-system 排除掉的。

然后是在 /etc/default/grub 里更新内核命令行 cryptdevice=/dev/disk/by-partlabel/ssd:ssd:allow-discards。这个 allow-discards 会轻微地降低安全性，不过在中国没什么用的。更新 /etc/fstab。

然后还有 /boot 要处理。其实就是把内核和 initrd 复制过去，然后重新安装 grub、生成 grub 配置。位于机械硬盘上的旧文件之后再删掉即可。

重启，使用 fallback 版 initrd 进入系统，开始修复各种问题。

首先是更新默认的 initrd。不过在更新它之前，我要修改一下我自己的 hook。之前这个 hook 里只有 partprobe 我解密之后的机械硬盘分区，因为我在它上边又分了 xfs 和 swap 两个区。现在因为 encrypt hook 解密的是 SSD 上的分区，所以这个机械硬盘上的加密分区的解密也要自己做。其实也很简单，给这个加密分区添加一下文件密钥，然后

cryptsetup open --type=luks --key-file=/etc/keys/hdd.luks /dev/disk/by-partlabel/main main

就可以了。不需要输入两次密码。

/ldata 使用 automount 延迟挂载，所以需要写 ldata.mount 和 ldata.automount 两个文件，然后 enable ldata.automount 那个。不知道写在 /etc/fstab 里是不是也行。然后把机械硬盘里的目录结构调整一下，把原来 /ldata 下的东西上移一级，旧的 / 里的其它东西都放到隐藏的 .oldroot 里去好了。

swap 本来我是保留着的，不过发现这样子我会时不时听到机械硬盘启动了。而且因为机械硬盘启动比较费时，所以系统会卡好一会儿（大概有一两秒）……所以我默认就不开 swap 了，但是 resume hook 还是保留，需要的时候打开 swap 就可以休眠了。这个 resume hook 也是我需要在启动的时候就解密机械硬盘上的加密分区的原因。

加了一个每周运行的 fstrim -v / cron 任务。没有使用 fstrim.timer 是因为它会 trim 所有设备。而我可不希望它去 trim 我挂载的机械硬盘上的 loop 设备，会造成大量碎片的。

还有一些小问题要处理。chattr +i /etc/resolv.conf 以避免 DNS 服务器被不知不觉修改了。我有用 dnsmasq 的所以这个文件不用动。我有一个 MediaWiki 实例的文件是使用 overlayfs 的，它现在挂载提示「failed to verify upper root origin」。后来才发现相关目录上有同步到几个 trusted. 开头的、overlayfs 使用的扩展属性。是它还挂载的时候被同步到的，不知道为什么最后一次同步时没有被清除掉。手动使用 setxattr 删除掉就好了。

rsync 还出了另外几个莫名其妙的问题。我在 /usr/local/sbin 下有个最近新加的文件的执行权限消失了，造成使用它的 systemd 服务失败。另外有个最近被删除的配置文件竟然还在。我不是有指定 --delete 选项吗？火狐缓存的网站图标也都没有了，需要访问之后才会重新出现。~/.cache 下有很多 root 所有的空目录，也许是我哪次忘记 --exclude 它然后又中断才加上？

Wine 有几个文件有几十 KiB 大的 user.wine.sd 扩展属性。太大了以至于 btrfs 里放不下，报「No space left on device」错误。我刚看到时还吓一跳，以为是我的 SSD 满了，仔细一看才发现只是扩展属性写不下而已。

我于是又带 --dry-run 参数同步了一次，确定再没有什么需要的东西被落下。这次 rsync 出现这些问题很是奇怪，不过我没有留日志，加上操作的时候其实是有不少修修改改的，所以就不深究了吧。

修好所有发现的问题，再次重启之后，systemctl status 和 systemctl --user status 没有失败项了～撒花 O(∩_∩)O~

后记

现在我的系统超快的！比如启动时间：

>>> systemd-analyze
Startup finished in 9.257s (firmware) + 1.466s (loader) + 15.110s (kernel) + 6.945s (userspace) = 32.780s 
graphical.target reached after 6.945s in userspace

firmware 和 loader 咱管不了。kernel 那儿包含了我输入密码解密，以及解密和探索机械硬盘上的分区，所以花了些时间。userspace 那里你别看花了好几秒，其实大部分时间都是花在联网上了。不依赖网络的服务在差不多一秒的时间内就全部启动好了。

之后我还要更新备份脚本，因为我用了 --one-file-system 而现在它们在不同的子卷上。再写一下每日快照的脚本，就不用一不小心删错文件啥的都要去备份里找了。

关于写入量，smartctl -a /dev/nvme0n1; sleep 300; smartctl -a /dev/nvme0n1 统计了一下，因为我开了 collectd 收集一些系统数据，每分钟大概会写入 60MiB 的数据。算下来，一年要写 20T 左右。这块 SSD 标称的是 280TBW，也就是可以写 280TB 的数据。这么算起来能用十年，所以就这样吧，不用再优化了。顺便说一下，SMART 信息里的「Data Units Written」数据，乘以 512000 之后是字节数。

就这样啦。最后还要说一句：SSD 超快的！

某天，我注意到系统日志中有如下报错：

ata2.00: exception Emask 0x0 SAct 0x80 SErr 0x0 action 0x0
ata2.00: irq_stat 0x40000008
ata2.00: failed command: READ FPDMA QUEUED
ata2.00: cmd 60/18:38:64:ad:96/00:00:00:00:00/40 tag 7 ncq 12288 in
         res 41/40:00:64:ad:96/00:00:00:00:00/00 Emask 0x409 (media error) <F>
ata2.00: status: { DRDY ERR }
ata2.00: error: { UNC }
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sdb] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sdb] tag#7 Sense Key : 0x3 [current] [descriptor] 
sd 1:0:0:0: [sdb] tag#7 ASC=0x11 ASCQ=0x4 
sd 1:0:0:0: [sdb] tag#7 CDB: opcode=0x28 28 00 00 96 ad 64 00 00 18 00
blk_update_request: I/O error, dev sdb, sector 9874788
bcache: bch_count_io_errors() sdb1: IO error on reading dirty data from cache, recovering
ata2: EH complete

啊，看来我的 SSD 要坏掉了么？！拿 bcache-status 看了一下状态，已经500多个报错了，但是我并没有遇到什么问题。看了一下 SSD 的 SMART 信息，也是500多个报错。这种报错出现已经有几天了，但是似乎影响并不大？SMART 报告也说「状况正常」。那就等有时间再处理好了，先把 bcache 缓存策略从「writeback」改成「writethrough」好了。我当时是这么想的。

出事的 SSD 是笔记本自带的，16G，被我用作缓存了。使用的是 bcache，一年之前我写文章讲过的。没想到刚刚一年，就开始出问题了。

过了一两天之后。我正上班中，同步 MediaWiki 数据时发现自己的机器又连不上了。我起初以为是网络问题，因为我记得很清楚我的机器是开着的。但是过了一会儿它还是不能访问。我 ping 了一下，却发现是通的！登陆到我作为路由器的树莓派上却发现，网络是正常的。能 ping 通笔记本，但是从树莓派上也 ssh 不了，访问 nginx 也没回应。所以笔记本还在线，但是系统出问题了。奇怪的是，访问另一端口上我用 Tornado 写的 Web 程序时却是正常的。

终于等到了下班。回到家里之后就听见笔记本风扇呼呼地响着。赶紧打开查看。htop 显示 journald 正在使用 CPU。于是去看 journald 日志，心里顿时凉了半截：日志只记录到上午，但满是上边那样的 SSD 报错。进一步的检查发现，/ 分区已经被挂载为只读，syslog-ng 日志比 journald 日志记录了更多的报错。火狐已经不知道什么时候挂掉了，并且启动不了。sudo 还是好的，但是运行 zsh 时会段错误。运行 bash 的话，会报一点错，可以看到有些文件已经变成无意义的数据了。bash 能启动，但是很奇怪的是，输入不了字符 e……想起还装了 dash，于是用这个连最基本的补全都没有的 shell，配合还没有挂掉的连着 VPS 的 mosh 上的 IRC 上网友们的帮助，尝试禁用 SSD 缓存。

结果是失败了。关于 bcache 有些资料与我看到的情况并不一致。重启会报一些错，然后我进入了 initramfs 里的 shell，尝试禁用 SSD，依旧失败中，脏数据写不回去，所以禁用不了缓存……不过看到了缓存中脏数据只有几百K。当然单位是什么我就不知道了……

放弃。又一天，我改从救援系统进入。记得有个工具能把普通分区转成 bcache。手机上网找到了，blocks。但是它并不能把 bcache 转回来。好在是开源项目，我读了一下代码，结合别人的说法，结论是：把普通分区转为 bcache，只要把分区缩小，在起始处空出一点空间，然后写入 bcache 的超级块就可以了。于是反过来，只要跳过 bcache 的超级块来读，就可以读到原来的分区数据了。

但是，bcache 超级块有多大呢？不知道。不过之前看到过一个扫数据的脚本，用类似的办法找一下分区数据的位置好了：

for i in {1..20}; do dd if=/dev/sda2 skip=$i | file -; done

file 显示在第8块的地方发现了「LUKS encrypted file」。这就是我要找的文件系统了！

为保险起见，先读读看。使用 losetup 把 /dev/sda2 映射成只读的 loop 设备，但是跳过开头的 8192 字节（dd 的块是 512 字节一个）。然后用 cryptsetup 解密。解密成功了。只读挂载解密之后的 ext4 文件系统。挂载成功了。看了一下内核日志，没有报错，没有警告。chroot 进去，正常，没有段错误，配置文件没有变成无意义的乱码。一切进行得好顺利！损坏程度比我以为的要轻不少呢！

为了确认损坏情况，我进行了一次模拟备份，也就是 rsync 的「--dry-run」选项。这样与最近的一次备份作比较，看看差异。结果很乐观，rsync 只报了十来个 I/O 错误。不过这也说明文件系统还是有问题的。

又一天。开始恢复系统了。还是从救援系统进入。进入 gdisk，删除原来的 sda2 分区，新建一个小了 8192 字节的分区。经验表明这样子删掉再重建分区表是没有问题的。也确实没出什么问题。不带 bcache 的文件系统出来了。解密之，然后使用 fsck 修复。修复过程中，fsck 问了我一大堆是不是要修复的问题。修复完毕之后，更改内核选项以便适应新的分区表，重启。

一切正常。不过根据之前 rsync 和修复过程中提到的文件名，去看了一下那些文件。都是最近更新系统时的一些 Python 文件。有一些文件消失了，另一些文件的权限和类型变得很奇怪。删掉，重装安装对应的软件包。完事了～不过没有了 SSD 缓存，能够感觉到有些操作会慢不少。

这 SSD 也真容易坏啊。刚刚一年呢。而且坏的过程很快，预警期只有几天。现在 SMART 报告已经出现过1000多个错误了，但整体评估还是「磁盘状况正常」……

好在我用的都是自由软件，虽然可能找遍整个互联网都没有个说法，但是还有实现它们的源码可以阅读，可以自己去思考解决方案。当然啦，就算这个 bcache 完全坏掉了，我也不需要太惊慌，因为我有备份嘛，更麻烦，但最多只损失几天的数据，不会突然之间什么都没有了。

换了新本子，外存是1T机械硬盘和16G固态硬盘。这16G SSD 速度挺快的尤其是读的时候，可它拿来放 / 都不够呢，于是拿来作缓存加速。根据局部性原理，虽然数据很多，但是最常访问的只占其中一小部分呢。

搜索的结果是有三个方案：bcache、dm-cache 和 Facebook 的 flashcache。前两者在官方内核里，不需要另外安装。我是最先在 Arch Wiki 上看到 bcache 的，后来又看 dm-cache，发现需要自己指定元数组的存储什么的，略复杂。而且一些评测显示 bcache 性能要好一点，所以就它了。

$$ \require{extpfeil} \rm{SSD} + \rm{HDD} \xlongequal{\rm bcache} \rm{SSHD} $$

配置起来其实很简单。首先安装 AUR 里的 bcache-tools，然后创建存储数据的分区和用于缓存的分区：

make-bcache -B /dev/sda2
make-bcache -C /dev/sdb1

教程上使用的是 SSD 的分区。换成 SSD 的块设备本身应该也可以。

参数什么的我没调。然后是把缓存设备的 UUID 写到 /sys/block/bcache0/bcache/attach 里。

为了最优性能，往 /sys/block/bcache0/bcache/cache_mode 里写入「writeback」来更改其缓存策略为「写回」。默认是「写通」（writethrough），也就是写的时候同时写缓存和后端设备，不会在缓存出问题时丢数据，但是会慢。另一个可选的策略是「writearound」，不知道该怎么译，是只写到后端设备而不写缓存的。最后一个是「none」，不知道用了它会发生什么……

换出策略使用默认的 LRU（最近最少使用）。剩下的两个（FIFO 和随机）应该效果没 LRU 好。

这些设备是会记住的，无需在启动时重启配置。至少我用的 4.0.1 内核是这样。

弄好之后就可以折腾 /dev/bcache0 这个块设备了。我放弃了之前使用文件级的 eCryptfs，改用在备份里使用得挺爽的块设备级的 dm-crypt，然后才格式化成 ext4。也就是：

$$ 文件数据 \xrightarrow{\textrm{I/O相关系统调用}} \rm{ext4} \xrightarrow{加密} \textrm{dm-crypt} \xrightarrow{缓存} \rm{bcache} \xrightarrow{写入} \rm{SSD} + \rm{HDD} $$

所以我的 /etc/mkinitcpio.conf 里要加上 bcache 和 encrypt 两个 hook：

HOOKS="base udev autodetect modconf block bcache encrypt filesystems keyboard fsck resume"

（不过这样子不能用外接 USB 键盘输入密码的。）

然后 mkinitcpio -p linux 一下，生成新的 initramfs 镜像。

为了共享缓存，我把 / 和 /home 放一起了（不过我猜对 /dev/bcache0 进行分区也是可以的？）。虽然这样子整个 / 用去了60多G空间，但是缓存的命中率还是非常高的——

>>> bcache-status -a
--- bcache ---
Device                      /dev/bcache0 (254:0)
UUID                        07a9b6a5-7f18-4950-84d6-c90abaaf65dc
Block Size                  0.50KiB
Bucket Size                 512.00KiB
Congested?                  False
Read Congestion             2.0ms
Write Congestion            20.0ms
Total Cache Size            14.91GiB
Total Cache Used            14.91GiB    (100%)
Total Cache Unused          0B  (0%)
Dirty Data                  0.50KiB     (0%)
Evictable Cache             14.17GiB    (95%)
Replacement Policy          [lru] fifo random
Cache Mode                  writethrough [writeback] writearound none
Last 5min Hits              439 (92%)
Last 5min Misses            38
Last 5min Bypass Hits       424 (100%)
Last 5min Bypass Misses     0
Last 5min Bypassed          61.50MiB
Last Hour Hits              46003       (88%)
Last Hour Misses            6051
Last Hour Bypass Hits       94043       (100%)
Last Hour Bypass Misses     0
Last Hour Bypassed          400.00MiB
Last Day Hits               79485       (88%)
Last Day Misses             10214
Last Day Bypass Hits        170383      (100%)
Last Day Bypass Misses      0
Last Day Bypassed           602.00MiB
Total Hits                  79485       (88%)
Total Misses                10214
Total Bypass Hits           170383      (100%)
Total Bypass Misses         0
Total Bypassed              602.00MiB

bcache-status 脚本来自这里。

感觉还挺快的，特别是各种程序如火狐、gvim、pidgin、zsh 的启动速度，以及 mlocate、pacman 的搜索速度都非常快。没有对比数据，因为我没有试过在这个本子上不用 bcache 的情况下把系统弄起来。之前的旧本子可能因为分区太满导致碎片严重，所以 I/O 性能很差劲的。