在法国用二手 NAS 跑 Docker，别把容器目录放在 RAID 上

上个月帮朋友重整他家那台二手 DS218j，DSM 7.1，两块 4T 盘做 SHR，Docker 套件是社区源装的。现象很具体：容器一多，套件中心转圈，File Station 打开共享目录要等三四秒，docker ps 本身很快，但 docker compose up 拉镜像解压时整机像卡住。数据量不大，2T 左右，问题不在容量。

我先看了 I/O 和内存。SSH 上去跑 iostat -x 2，md0 的 %util 常年贴着 100，await 二三十毫秒，而 free 显示 1G 内存已经吃满，swap 在动。DS218j 是 ARM 加 512M 内存的机器（朋友那台实际是 1G 版本），容器镜像解压和元数据写入全落在 RAID 上，元数据一多，机械盘就顶不住。

做法是把 Docker 的根目录挪到外接 USB3 SSD 上，RAID 只放数据。先停套件：

synopkg stop Docker
sudo mv /volume1/@docker /volume1/@docker.bak
sudo mkdir -p /volumeUSB1/usbshare/docker
sudo mount --bind /volumeUSB1/usbshare/docker /volume1/@docker

再把 bind mount 写进开机脚本，DSM 的计划任务里加一条「触发的任务」，开机执行上面那行 mount --bind，否则重启后容器全找不到。/etc/fstab 在 DSM 升级时容易被覆盖，我没用它。

为什么这样：Docker 的瓶颈通常不是大文件读写，而是大量小文件和 overlay2 的层元数据，机械盘随机写扛不住；USB3 SSD 的顺序带宽一般，但随机 IOPS 够用。代价是外接盘掉线容器就全停，而且 DSM 对 USB 存储的休眠策略要手动关，不然盘睡下去容器会假死。

会失效的地方：一是 DSM 大版本升级会重建 /volume1/@docker，bind mount 得重做；二是套件源装的 Docker 升级时可能覆盖启动脚本，我踩过一次，升级后容器全丢，只能从 @docker.bak 里把 containers 目录拷回来；三是 USB 口供电不稳的机器别这么干，掉盘比机械盘慢更难受。另外 SHR 上跑数据库类容器，哪怕目录挪走了，数据文件还在 RAID 上，该慢还是慢。

你们在 ARM 小机器上跑 Docker，是接受外接盘，还是干脆把元数据留在 RAID、只把日志和临时目录挪出去？后一种我没试过，不确定 overlay2 能不能只拆一部分。