上一次写博客还是 2021 年，好久远。

这次是写如何给 qBittorrent 配置 mergerfs 来合并多个磁盘。

这是一个错误的选择，只是看上去很美好。

最开始的原始操作

最初，我是手动分配下载路径，使用的是 qBittorrent 4.5.5 libtorrent 1.2，默认的 mmap 性能非常好。竞速刷流下也可以充分利用内存，缓解 HDD 的随机 IO 缺点。

但总觉得手动分配路径有些麻烦，有点手痒想换方便点的。

mergerfs

后来看到有 https://wzyboy.im/post/1148.html 在 NAS 上配置 mergerfs 来合并文件系统，空间利用率最大化和保持下层文件系统形态等非 RAID 特点我也喜欢，于是我决定尝试一下。

mergerfs 是一个基于 FUSE 的用户空间文件系统，可以将多个目录合并成一个虚拟文件系统。

基于 mergerfs 的 README：由于 libtorrent 1.2 使用 mmap，我开启了 cache.files=partial。

fstab 内容如下：

1
/mnt/3t:/mnt/2t /mnt/merger fuse.mergerfs defaults,allow_other,minfreespace=10G,cache.files=partial,fsname=mergerfs,ignorepponrename=true 0 0

然而在使用 qBittorrent 4.5.5 libtorrent 1.2 版本时，mmap 下一直 iowait 85%，性能奇差。

在 https://www.reddit.com/r/OpenMediaVault/comments/tbuue5/qbittorrent_can_now_broken_with_mergerfs_by/ 看到有人说 posix 的 IO 模式可以缓解。对于 libtorrent 2.0，可以更改磁盘 IO 类型。于是升级到了 qBittorrent 4.6.4 libtorrent 2.0，并尝试了 mmap 和 posix 两种 IO 模式。mmap 模式下的问题依旧存在，而 posix 模式下的 iowait 有所降低，但仍然高达 45%，性能奇差，不论是面食大包（很多随机磁盘 IO）还是竞速刷流（大部分可以由内存抗住）速度都很慢。而且 libtorrent 2.0 本身就用着怪怪的。

于是我放弃了这个方案并回滚到原始操作的方案。不过对于很少 IO 操作的场景，基于 FUSE 的 mergerfs 用起来还挺舒服。

iBug 的 overlayfs

但是如果只是要看合并后的文件系统，完全就不需要使用 FUSE。可以用自带的 overlayfs，让上层用户更方便地访问合并后的文件系统。由于我不需要写操作，所以就不设定 upperdir 和 workdir：

1
2
3
4
5
6
7
$ mount -t overlay -o lowerdir=/mnt/3t:/mnt/2t overlay /mnt/merger
$ ls merger/qbt/ | wc
    234    1464   14534
$ ls 2t/qbt/ | wc
     41      42    2927
$ ls 3t/qbt/ | wc
    195    1424   11711

可以看到内容实现了叠加。