小文件为什么慢
处理一个小文件要经历打开、查询属性、读取、关闭等多个往返，传输的数据却只有几 KB。在局域网里单个文件耗时以毫秒计，十万个文件就是数百秒，而这期间带宽利用率可能不到百分之几。因此优化目标不是提高带宽，而是减少往返次数与提升操作并行度：打包成归档、减少每次操作涉及的文件数、让多个流同时推进、让缓存承担重复访问。
基本信息
| 适用平台 | SMB/NFS 共享上的代码仓库、构建产物、日志与文档集 |
|---|---|
| 关键指标 | 每秒文件数、单文件平均耗时 |
| 协议侧手段 | 目录缓存与租约、属性缓存时间 |
| 客户端侧手段 | 打包传输、提高并行度、减少目录枚举 |
| 服务端侧手段 | 元数据性能、日志与同步写策略 |
优化手段与代价
| 手段 | 收益 | 代价或风险 |
|---|---|---|
| 打包为归档再传输 | 往返次数大幅下降 | 需要解包步骤与额外空间 |
| 提高并行度 | 接近链路与元数据能力上限 | 服务端并发压力上升 |
| 目录与属性缓存 | 重复枚举与查询变快 | 一致性窗口变大 |
| 关闭访问时间更新 | 减少写侧元数据开销 | 失去访问时间信息 |
| 把元数据放到更快介质 | 枚举与查询更快 | 需要存储层规划与成本 |
常见做法对比
常见做法对比
# 逐个复制十万个小文件：往返次数最多
cp -r /src/smallfiles /mnt/data/
# 先打包再搬：显著减少往返
tar -cf - -C /src smallfiles | tar -xf - -C /mnt/data
# Windows 侧用多线程复制提高并行度
robocopy C:\src D:\dst /MIR /MT:16
# 用多流同步工具提高小文件吞吐
rsync -a --info=progress2 /src/smallfiles/ /mnt/data/smallfiles/评估小文件负载时应统计每秒处理的文件数并与目标比对，而不是看 MB/s。同样的共享目录上，大文件顺序读写与小文件元数据操作几乎是两种不同的工作负载，容量与性能结论要分开给出。
安全软件与索引程序对小文件的实时扫描会成倍放大开销，且现象是「磁盘和网络都不忙但很慢」。这类负载应通过排除策略或分批扫描来控制，而不是一味升级硬件。