eBPF+Ftrace 合璧剑指：no space left on device？

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475
本文地址：https://www.ebpf.top/post/no_space_left_on_devices

最近在生产环境中遇到了几次创建容器报错 ”no space left on device“ 失败的案例，但是排查过程中发现磁盘使用空间和 inode 都比较正常。在常规的排查方式都失效的情况下，有没有快速通用思路可以定位问题根源呢？

本文是在单独环境中使用 eBPF + Ftrace 分析和排查问题流程的记录，考虑到该方式具有一定的通用性，特整理记录，希望能够起到抛砖引玉的作用。

作者水平有限，思路仅供参考，难免存在某些判断或假设存在不足，欢迎各位专家批评指正。

1. ”no space left on device“ ???

本地复现的方式与生产环境中的问题产生的根源并不完全一致，仅供学习使用。

在机器上运行 docker run ，系统提示 “no space left on device” ，容器创建失败：

|  | $ sudo docker run --rm -ti busybox ls -hl|wc -l |
|  | docker: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/40de1c588e43dea75cf80a971d1be474886d873dddee0f00369fc7c8f12b7149-init/merged:  |
|  | no space left on device. |
|  | See 'docker run --help'. |

错误提示信息表明在 overlay mount 过程中磁盘空间不足，通过 df -Th 命令进行确定磁盘空间情况，如下所示：

|  | $ sudo df -Th |
|  | Filesystem Type Size Used Avail Use% Mounted on |
|  | tmpfs tmpfs 392M 1.2M 391M 1% /run |
|  | /dev/sda1 ext4 40G 19G 22G 46% / |
|  | tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm |
|  | tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock |
|  | /dev/sda15 vfat 98M 5.1M 93M 6% /boot/efi |
|  | tmpfs tmpfs 392M 4.0K 392M 1% /run/user/1000 |
|  | overlay overlay 40G 19G 22G 46% /root/overlay2/merged |

但磁盘空间使用情况表明，系统中挂载的 overlay 设备使用率仅为 46%。根据一些排查经验，我记得文件系统中 inode 如耗尽也可能导致这种情况发生，使用 df -i 对于 inode 容量进行查看：

|  | $ sudo df -i |
|  | Filesystem Inodes IUsed IFree IUse% Mounted on |
|  | tmpfs 500871 718 500153 1% /run |
|  | /dev/sda1 5186560 338508 4848052 7% / |
|  | tmpfs 500871 1 500870 1% /dev/shm |
|  | tmpfs 500871 3 500868 1% /run/lock |
|  | /dev/sda15 0 0 0 - /boot/efi |
|  | tmpfs 100174 29 100145 1% /run/user/1000 |
|  | overlay 5186560 338508 4848052 7% /root/overlay2/merged |

从 inode 的情况看，overlay 文件系统中的 inode 使用量仅为 7%，那么是否存在文件被删除了，但仍被使用使用延迟释放导致句柄泄露？抱着最后一根稻草，使用 lsof |grep deleted 命令进行查看，结果也一无所获：

|  | $ sudo lsof | grep deleted |
|  | empty |

常见的错误场景都进行了尝试后，仍然没有线索，问题一下子陷入了僵局。在常规排查思路都失效的情况下，作为问题排查者有没有一种不过于依赖内核专业人员进行定位问题的方式呢？

答案是肯定的，今天舞台的主角属于 ftrace 和 eBPF (BCC 基于 eBPF 技术开发工具集）。

2. 问题分析及定位

2.1 初步锁定问题函数

常规的方式，是通过客户端源码逐步分析，层层递进，但是在容器架构中会涉及到 Docker -> Dockerd -> Containerd -> Runc 一系列链路，分析的过程会略微繁琐，而且也需要一定的容器架构专业知识。

因此，这里我们通过系统调用的错误码来快速确定问题，该方式有一定的经验和运气成分。在时间充裕的情况下，还是推荐源码逐步定位分析的方式，既能排查问题也能深入学习。

”no space left on device“ 的错误，在内核 include/uapi/asm-generic/errno-base.h 文件定义：

一般可以拿报错信息在内核中直接搜索。

|  | #define ENOSPC 28 /* No space left on device */ |

BCC 提供了系统调用跟踪工具 syscount-bpfcc，可基于错误码来进行过滤，同时该工具也提供了 -x 参数过滤失败的系统调用，在诸多场景中都非常有用。

请注意&