假设我们使用以下命令打开了一个文件fopen()并从收到的文件指针中，使用以下命令获取文件描述符fileno()。然后我们做很多（>10^8）随机read()该文件中相对较小的块，大小在 4 字节到 10 KB 之间：
这是预期的行为吗read()可能会返回比请求更少的字节，无需设置errno，如果文件系统是
ext3
NFS
OCFS2
2 和 3 的组合（OCFS2 via NFS)
?
我的阅读给了我这样的结论：1.（如果文件没有O_NONBLOCK设置，如果可能的话ext3设置它）但对于其他三个（2.、3.、4.）我不确定。
（顺便说一句：我可以假设有O_NONBLOCK在任何情况下都没有设置为默认值？）
出现这个问题是因为我观察到read()返回的字节数少于请求的字节数errno设置为情况 4。
通过测试进行深入研究的问题是，这种行为发生在
Update：平均文件大小在几 TByte 到 1 GByte 左右。
您不应假设 read() 返回的字节数不会少于任何文件系统所请求的字节数。在大量读取的情况下尤其如此，因为 POSIX.1 指示大于 SSIZE_MAX 的大小的 read() 行为取决于实现。在我现在使用的主流 Unix 机器上，SSIZE_MAX 是 32767 字节。 read() 今天总是返回全部金额这一事实并不意味着将来也会如此。
一个可能的原因可能是 I/O 优先级将来会在内核中得到更充分的充实。例如。您正在尝试从与另一个更高优先级进程相同的设备进行读取，如果您的进程没有导致头部移动远离其他进程想要的扇区，则另一个进程将获得更好的吞吐量。内核可能会选择给你的 read() 一个简短的计数，让你暂时摆脱困境，而不是继续进行低效的交错块读取。更奇怪的事情已经做了 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781?comments=all为了提高 I/O 效率。不被禁止的事情往往会变成强制性的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
