POSIX statvfs()描述说：
可以在f_flag成员中返回以下标志：
ST_RDONLY-只读文件系统。
ST_NOSUID-exec忽略的Setuid / setgid位。
尚不确定statvfs结构的所有成员在所有文件系统上是否都具有有意义的值。
另外sys/statvfs.h说明：<sys/statvfs.h>头应为f_flag成员定义以下符号常量：
ST_RDONLY-只读文件系统。
ST_NOSUID-不支持ST_ISUID和ST_ISGID文件模式位的语义。
如何正确解释呢？我的意思是：
是否允许POSIX兼容系统在ST_RDONLY有意义的情况下返回废话？
如果statvfs结构成员对特定文件系统有意义，那么是否允许OS返回废话（我知道某些字段对于/ proc这样的合成文件系统可能没有任何意义）？
是否有任何操作系统声称用于存储数据/可执行文件的文件系统返回错误的ST_RDONLY或ST_NOSUID，同时声称它的statvfs()实现具有POSIX兼容性？
最佳答案
除了它的存在外，POSIX规范几乎不需要statvfs()。
特别是，它要求statvfs()用“有关文件系统的信息”填充指定的struct statvfs *缓冲区，但不能保证该信息的含义。换句话说，它可能是完全的垃圾，实际上是在许多系统上（包括OS X上的HFS +）。
其中包括f_flag的struct statvfs成员，可以将其掩码为ST_RDONLY和/或ST_NOSUID，但许多成员并非位于所有文件系统上（即使应该存在）。
如果您需要跨多个平台可靠地获取文件系统信息，则（具有讽刺意味的是）您可能不得不求助于诸如statfs()之类的非标准化功能。但是，在Linux上，statvfs()在大多数非合成文件系统上的表现都很好。