AWS Batch作业启用EBS自动扩缩仍报No space left on device错误

问题原因及解决方法 #

核心问题1：自动扩缩触发滞后+初始容量不足 #

bbnorm处理2个22G的fq.gz文件时，解压后的原始测序数据、运行过程生成的k-mer计数文件、临时校正文件的总占用峰值通常超过200G。你当前配置的docker存储卷初始容量仅为100G，而amazon-ebs-autoscale默认在磁盘使用率达到90%时才触发扩容，扩容需要30-60秒的EC2 API调用和卷初始化时间，这个窗口内作业持续写入就会直接触发空间不足报错。

• 解决方法：把/dev/sdc对应的EBS卷初始容量从100G调整到250G以上，也可以修改amazon-ebs-autoscale的触发阈值到70%，提前触发扩容避免滞后。

核心问题2：临时文件写入路径未纳入自动扩缩范围 #

你当前配置的自动扩缩仅管理/var/lib/docker目录，如果你的bbnorm.sh作业把临时文件写到了容器根目录，或是映射到了主机/tmp、/root这类挂载在根卷（/dev/xvda仅50G）的路径，自动扩缩的EBS卷不会承接这部分写入，根卷占满就会报错。

• 解决方法：修改bbnorm.sh运行参数，指定tmpdir参数到容器内映射到docker存储的路径，或是在Batch作业定义里把临时目录的挂载点绑定到/var/lib/docker对应的宿主路径。

核心问题3：btrfs存储驱动配额限制 #

你当前使用的docker存储驱动为btrfs，默认对单个容器的可写入层有容量限制，若未调整配额，哪怕宿主磁盘还有剩余空间，容器写入达到配额也会报空间不足。

• 解决方法：在docker启动参数中添加btrfs配额调整配置，或是在作业定义里为容器配置更大的存储限额。

验证步骤 #

• 作业运行前可登录Batch计算节点，运行df -h查看各挂载点的容量和路径，确认自动扩缩卷已正确挂载到/var/lib/docker
• 查看/var/log/ebs-autoscale-install.log确认自动扩缩服务安装成功，运行systemctl status amazon-ebs-autoscale确认服务正常运行
• 调整配置后可先跑小文件测试验证扩容逻辑正常，再运行22G的大文件作业

内容的提问来源于stack exchange，提问作者spitfiredd