多进程调用FFmpeg切割WenetSpeech数据集音频时，磁盘空间充足却报错“No space left on device”

嘿，我太懂你这种崩溃的感觉了——处理WenetSpeech这种超大规模的数据集，本来想用多进程+FFmpeg批量切音频段提速，结果跑了大半天突然炸出个“No space left on device”，但翻遍磁盘信息发现空间明明还剩一大截，这简直是离谱到家了！

结合你给出的FFmpeg命令和场景，我帮你捋几个最可能的原因和对应的解决办法：

1. 先查：FFmpeg临时文件把小容量tmpfs占满了 #

你用的是-c copy流复制模式，FFmpeg在处理同一个输入的多个输出段时，会在临时目录生成缓存文件来处理时间戳对齐这类操作。而很多系统默认把/tmp挂载成tmpfs（用内存当临时盘），容量一般只有几G到十几G。当你开了N多进程，每个FFmpeg又在生成一堆临时文件，跑不了多久就会把tmpfs撑爆，这时候就会报“空间不足”——但你的数据盘其实还空着呢！

解决办法：
直接给FFmpeg指定一个在大容量数据盘上的临时目录，在命令开头加上-tmpdir参数就行。比如：

ffmpeg -tmpdir /host_ssd1/mooki/ffmpeg_tmp -loglevel warning -y -i input_file.opus -ss beginTime1 -to endTime1 -c copy output_file1.opus ...

记得提前创建这个临时目录，并且确保它的权限是当前用户可读写的。

2. 再查：系统文件描述符被耗尽了 #

你要生成1700多万个小文件，再加上多进程同时跑，每个FFmpeg进程又要同时创建好几个输出文件，很容易触发系统的文件描述符上限（默认一般是1024或者4096）。当打开的文件数量超过这个上限时，新的文件创建会失败，而FFmpeg有时候会把这个错误误导性地提示成“No space left on device”。

解决办法：

• 临时救急：在启动Python脚本之前，先在终端里执行ulimit -n 65535，把当前会话的文件描述符上限调高到65535（足够应付大量小文件了）。
• 长期生效：编辑/etc/security/limits.conf，添加两行：

  * soft nofile 65535
  * hard nofile 65535
  

  保存后重启终端或者重新登录，这个限制就会永久生效。
• 优化命令：你现在一个FFmpeg命令切多个段，虽然能减少重复读输入的开销，但如果每个输入要切的段数太多，不如拆分命令——比如让每个FFmpeg进程只处理3-5个输出段，避免同时打开太多文件句柄。

3. 容易被忽略的点：磁盘inode耗尽 #

你要生成1700多万个小文件，每个文件都会占用一个inode（文件系统用来记录文件元数据的节点）。哪怕你的磁盘空间还够，如果inode被用完了，也会报“空间不足”的错误。

排查&解决：

• 用df -i命令查看磁盘的inode使用情况，比如看/host_ssd1分区的inode使用率，如果是100%，那就是这个问题。
• 解决办法：把输出文件按目录分桶存放，比如给每个输入音频文件创建一个子目录，把它对应的所有切割段放进去，这样能稍微缓解；更根本的是用适合大量小文件的文件系统，比如XFS（比ext4支持的inode数量更多，性能也更好）。如果已经是ext4，也可以在格式化的时候指定更多的inode数，但这个得重新格式化，所以得先备份数据。

最后再提个小建议 #

你贴的FFmpeg错误日志被截断了，下次遇到这种情况，尽量把完整的错误信息捞出来——比如有没有提到“tmp file”或者“Too many open files”的关键词，这些能直接帮你定位问题。

备注：内容来源于stack exchange，提问作者MookiXiao