☰

在什么类 UNIX 系统/文件系统上，stat() 返回的 st_blocks 字段不是一些 512 字节单位？

tag-icon • tag-icon stat portability api
在什么类 UNIX 系统/文件系统上，stat() 返回的 st_blocks 字段不是一些 512 字节单位？

我总是假设/ ... 系统调用st_blocks返回的字段用于获取文件的磁盘使用情况以 512 字节为单位表示。stat()lstat()du

检查POSIX规范，我现在看到 POSIX 对此没有做出保证。perl其自身stat()功能的文档还警告不要做出这种假设。

st_blksize无论如何，正如 POSIX 所指示的，该块大小与返回的字段无关stat()，因此必须在其他地方找到。

检查 GNUdu或 GNUfind源代码，我看到 HP/UX 使用 1024 字节单位的证据。 GNUfind调整其-printf %b输出以始终提供多个 512 字节单位，这可能是我困惑的根源。

目前是否还有其他仍在使用的类 Unix 系统不是st_blocks以 512 字节为单位表示的？这可以依赖于文件系统吗（正如 POSIX 所建议的那样）？我想安装 HP/UX NFS 共享可以做到这一点。

答案1

st_blksize称为“最佳 I/O 大小”，与 所使用的单位无关st_blocks。当然，最佳 I/O 大小是特定于文件系统的。这是fast filesystem1981/1982 年 Berlekey 开发的结果。以前，可用文件系统中没有最佳块大小

st_blocks以 为单位表示，DEV_BSIZE在 HP-UX 上确实是 1024。DEV_BSIZE是特定于平台的常量。后来，当FFS重命名为时UFS，BSD UNIX 中出现了第二个文件系统，它具有与间接块相关的不同行为，并且需要这个新stat()字段。之前，du只知道文件系统中间接块的算法。

如果您运行 HP-UX NFS 文件服务器和其他 NFS 客户端，您会从 HP-UX NFS 服务器收到错误报告，除非dfHP 在过去 15 年中修复了他们的问题，而我无法访问最新版本的 HP-UX 。据我所知，没有其他 UNIX 存在类似的 NFS 相关错误。

顺便说一句：直到 NFSv3，NFS 假定块大小为 512，HP 需要在服务器中转换其 NFS 报告。 NFSv4 没有做出这种隐含的假设，但 HP-UX 仍然报告错误的数字。

据我所知，没有其他 UNIX 是基于 1024 的DEV_BSIZE。

相关内容