<p>statvfs() 是最便携的 POSIX 方式，用于获取文件系统级块与 inode 统计，但不支持用户/组配额查询；f_bsize 是推荐 I/O 块大小，f_frsize 才是基本分配单元，计算容量必须用 f_bavail * f_frsize。</p>
直接说结论：用 statvfs() 是最便携、最接近底层块大小与配额统计的 POSIX 方式，但它不返回用户/组配额（quota），只提供文件系统级的空闲/总块数和 inode 统计；真要查磁盘配额，得调用 quotactl()（Linux）或解析 /proc/quota 等非标准接口。
为什么 statvfs() 返回的 f_bsize 和 f_frsize 不一样？
f_bsize 是“文件系统推荐的 I/O 块大小”，用于优化读写性能（比如 read()/write() 传入该尺寸效率最高）；f_frsize 才是“文件系统基本分配单元”（fundamental filesystem block size），即实际磁盘分配的最小粒度，所有 f_blocks、f_bfree 等字段都按它计算。
常见误区是把 f_bsize 当作底层块大小——它可能被内核动态调整（如 ext4 的 big_writes 模式），而 f_frsize 才稳定反映格式化时的 -b 参数值（如 mke2fs -b 4096）。
-
f_frsize通常等于或小于f_bsize；ext4/xfs 一般两者相等，zfs 可能不同 - 计算可用字节数必须用
f_bavail * f_frsize，不是f_bavail * f_bsize - 某些 NFS 挂载会将
f_frsize设为 512，但实际分配以服务器端为准，不可靠
如何用 statvfs() 安全获取存储容量与剩余空间
关键不是调用成功，而是理解哪些字段受 root 权限、挂载选项或文件系统类型影响。例如：f_bfree 对普通用户可见，但 f_bavail（非特权用户可用块数）才是真实可用值——它已扣除保留块（如 ext4 的 5% reserved blocks）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
示例片段（带错误检查）：
struct statvfs buf;
if (statvfs("/home", &buf) != 0) {
perror("statvfs");
return -1;
}
uint64_t total_bytes = buf.f_blocks * buf.f_frsize;
uint64_t avail_bytes = buf.f_bavail * buf.f_frsize; // 注意是 f_bavail，不是 f_bfree
- 路径必须是**已挂载目录**（不能是符号链接顶层，否则返回父挂载点数据）
- 若目标路径跨 bind mount 或 overlayfs，
statvfs()返回的是最底层文件系统数据，不是挂载视图 - 某些容器环境（如 rootless Podman）中，
f_bavail可能为 0，需 fallback 到f_bfree并 warn
statvfs() 为什么查不到用户配额（user quota）？
statvfs() 是文件系统抽象层接口，设计目标就是屏蔽上层策略（如 quota、ACL、encryption）。它只回答“这块硬盘总共多大、还剩多少”，不回答“张三还能写多少”。Linux 下查用户配额必须用 quotactl() 系统调用，配合 QCMD(Q_GETQUOTA, ...)，且需要 CAP_SYS_ADMIN 或 root 权限。
- 没有标准 C++ 封装，需手写 syscall 或用
libquota（非 libc 自带） - ext4/btrfs 支持项目配额（project quota），但
statvfs()完全无感知 - macOS / FreeBSD 用
getfsstat()+statfs()，同样不包含 quota 字段
真正难的不是调用接口，而是判断“当前路径是否启用了配额”——得先 open("/proc/mounts") 扫描 usrquota/grpquota 选项，再确认 /aquota.user 是否存在，最后才调 quotactl()。这些步骤缺一不可，漏掉就只能得到“Operation not permitted”或静默失败。
