应使用 statvfs() 获取文件系统真实逻辑块大小，因其 f_frsize 字段准确返回基本分配单元大小；stat() 不提供该信息，st_blksize 仅为建议缓冲区大小，且 statfs() 在不同内核版本中语义不一致。
直接用 statfs 或 statvfs，别碰 stat —— 它不返回块大小。
为什么 stat 拿不到 Block Size
stat（包括 stat()、fstat()）只提供文件自身元信息：st_size、st_blocks（以 512 字节为单位的已分配块数），但不暴露底层文件系统的真实逻辑块大小（如 4096）。这个值由文件系统在挂载时决定，必须查 statfs 或 statvfs。
常见错误现象：
- 误把 st_blksize 当作文件系统块大小（它只是“建议 I/O 缓冲区大小”，可能被内核或 libc 调整，不一定等于实际 fs block size）
- 对不同路径反复调用 stat() 期望得到一致的块大小，结果发现 st_blksize 在 ext4 和 XFS 下差异大，且和 getconf FRAGSIZE /path 输出不一致
statvfs 是更可移植的选择
statvfs 是 POSIX 标准接口，语义清晰，字段名直白；statfs 是 Linux 特有，字段含义随内核版本变动（比如 struct statfs 的 f_bsize 在旧内核里是“首选 I/O 块大小”，新内核里才接近真实逻辑块大小）。
实操建议：
- 优先用 statvfs()，头文件是 <sys/statvfs.h>
- 关键字段是 f_frsize：文件系统“基本分配单元”大小（即逻辑块大小），单位字节
- f_bsize 是“文件系统推荐的 I/O 块大小”，通常等于 f_frsize，但某些网络文件系统（如 NFS）可能不同
- 不要用 f_bsize 替代 f_frsize 做内存对齐或扇区计算
#include <sys/statvfs.h>
struct statvfs sv;
if (statvfs("/home", &sv) == 0) {
printf("Block size: %lu\n", sv.f_frsize); // ✅ 真实逻辑块大小
}
注意 f_frsize 和 f_bsize 的实际差异场景
大多数本地文件系统（ext4、XFS、btrfs）下 f_frsize == f_bsize，但以下情况会不等：
- NFSv4 挂载时，f_bsize 可能反映客户端缓存块大小（如 65536），而 f_frsize 是服务端真实块大小（如 4096）
- tmpfs 返回 f_frsize = 4096，但 f_bsize 可能是 1024（取决于内核配置）
- 使用 mount -o bs=8192 这类非标准选项时，f_bsize 可能被覆盖，f_frsize 仍保持文件系统原始值
所以：
- 做 mmap 对齐、direct I/O 缓冲区分配 → 用 f_frsize
- 做 read/write 缓冲区优化（非 O_DIRECT）→ 可参考 f_bsize，但 libc 的 BUFSIZ 更可靠
- 不要假设二者恒等，尤其在容器或远程挂载环境里
兼容性与性能提醒
statvfs() 调用开销极小（内核直接从 superblock 拷贝，无磁盘 I/O），但要注意：
- 路径必须存在且可访问（哪怕只是目录），否则返回 -1 并设 errno = ENOENT 或 EACCES
- 如果目标路径是符号链接，statvfs() 默认解引用（类似 stat），要查链接本身得先 readlink + dirname 再调用
- 在 musl libc（Alpine）下，statvfs 行为与 glibc 一致，无需额外处理
- 避免在 tight loop 中反复调用——块大小不会变，缓存一次就够了
真正容易被忽略的是：很多 C++ 封装库（如 boost::filesystem）根本不暴露 f_frsize，它们的 space() 方法只返回 f_bsize。这时候你得绕过封装，亲手调 statvfs。
立即学习“C++免费学习笔记（深入）”；
