很明显，通常 read(2) 系统调用返回的字节数少于请求读取的字节数。然而，相当多的程序假设在处理本地文件时，read(2) 永远不会返回少于所要求的内容（当然，除非文件更短）。
所以，我的问题是：在 Linux 上，如果从打开的文件中读取并且没有遇到 EOF 并且正在读取的量最大为几千字节，那么在哪些情况下 read(2) 返回的值可能小于请求的值？
一些猜测：
【问题讨论】：
标签： c linux filesystems system-calls
我一直读到的被称为“短读”的内容与文件访问 read(2) 无关，而是与磁盘扇区的物理读取有关。当读取扇区的数据部分时，发现的有效磁信号比生成扇区的 512（或 4096 或其他）字节少时，就会发生这种情况。这会导致无效扇区和读取错误。关于“何时”，或者更确切地说，为什么会发生这种情况，很可能是因为在写入该扇区时驱动器的电源下降了。
会不会是 read(2) 以称为“短读”的物理错误代码结束？
【讨论】：
我不确定，但是当操作系统的页面缓存中的页面用完时，可能会出现这种情况。您可以建议在这种情况下调用刷新线程，但这取决于 I/O 调度程序中使用的启发式方法。这种情况可能会导致读取返回的字节数减少。
【讨论】：
返回的值可能小于 nbyte 如果剩下的字节数 文件小于 nbyte，如果 read() 请求被一个 信号，或者如果文件是管道或 先进先出或特殊文件，具有较少 超过 nbyte 个字节立即可用 供阅读。
基于磁盘的文件系统通常使用不间断读取，这意味着
读操作一般不能被信号中断。基于网络
文件系统有时使用可中断的读取，它可以返回部分数据或不返回数据。
（对于 NFS，这可以使用 intr 挂载选项进行配置。）
他们有时也会实现超时。
请记住，即使 /some/arbitrary/file/path 也可能指的是 FIFO 或 特殊文件，所以你认为是普通文件的可能不是。因此是 处理部分读取的良好做法，即使它们不太可能发生。
【讨论】：
如果它确实是您正在阅读的文件，那么您可以将短读作为文件结束前的最后一次读取。
但是，通常最好表现得好像任何读取都可以是短读取。如果您正在读取的是管道或输入设备 (stdin) 而不是文件，则只要您的缓冲区大于输入缓冲区中的当前值，您就可以进行短读取。
【讨论】：
我不得不问：“你为什么在乎原因”？如果 read 可以返回比请求数量少的字节数（正如您所指出的，它当然可以）为什么您不想处理这种情况？
【讨论】：
接收到的信号只有在尚未读取单个字节时才会使 read() 失败。否则会返回部分数据。
而且我猜在其他情况下，备用文件系统可能确实会返回短读取。例如，（对我来说）让基于网络的文件系统表现得像网络套接字一样具有短读取（= 经常使用它们）是有道理的。
【讨论】：