这是典型的 inode 耗尽问题，rsync 写入大量小文件时即使磁盘块充足，若目标分区 inode 用尽（df -i 显示 IUse% ≥95%）也会报“No space left on device”。
rsync 报 “No space left on device” 但 df -h 显示空间充足
这是典型的 inode 耗尽问题。rsync 在写入新文件（尤其是大量小文件）时，即使磁盘块还有富余，只要目标分区的 inode 用完了，就会触发该错误。此时 df -h 看起来一切正常，但 df -i 会显示 Use% 接近或等于 100%。
确认是否为 inode 耗尽：用 df -i 检查目标挂载点
运行 df -i /path/to/dest（把 /path/to/dest 替成你的 rsync 目标目录所在挂载点），重点关注三列：
-
Inodes：总 inode 数 -
IUsed：已用 inode 数 -
IUse%：使用百分比 —— 若 ≥95%，基本可判定是瓶颈
注意：不同文件系统默认 inode 数量策略不同。例如 ext4 默认按每 16KB 分配一个 inode；若存大量极小文件（如日志、缓存、Git 对象），很容易提前耗尽。
临时缓解：清理无用小文件，而非扩大 inode
inode 数量在格式化时固定（ext* 系统无法在线扩容），所以不能“加 inode”，只能释放。常见操作包括：
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
- 查找并删除零字节文件：
find /mnt/dest -xdev -type f -size 0 -delete - 清理重复或过期的缓存目录（如
node_modules、.cache、__pycache__） - 检查是否有被误删但仍被进程占用的文件（
lsof +L1可发现） - 避免 rsync 带
--delete后又中断 —— 中断可能导致部分旧文件残留，而新文件又不断生成
长期预防：创建文件系统时预留足够 inode，或改用更适合小文件的方案
下次格式化目标磁盘时，可显式指定 inode 密度。例如 ext4 下：
mkfs.ext4 -i 8192 /dev/sdX1
其中 -i 8192 表示「每 8192 字节分配一个 inode」（默认通常是 16384），数值越小，inode 越多。但注意：过多 inode 会浪费磁盘元数据空间，且影响 ls 和 find 性能。
更务实的做法是：对纯小文件场景（如对象存储代理层），考虑 XFS（默认 inode 动态分配）或 Btrfs；或者用归档压缩（tar + gzip）替代直接同步大量碎片文件。
真正麻烦的不是报错本身，而是 rsync 不会告诉你到底是块空间还是 inode 满了 —— 必须手动 df -i 才能定位。这点容易被跳过，尤其当运维习惯只看 df -h 的时候。
