一般に、read（2）システムコールは、読み取られるように要求されたバイトよりも少ないバイトを返すことができることは明らかです。ただし、かなりの数のプログラムは、ローカルファイルを操作するときに、read（2）が要求されたものよりも少なくなることはないと想定しています（もちろん、ファイルが短い場合を除きます）。
だから、私の質問は：Linuxでは、開いているファイルからの読み取りが行われず、読み取られる量が最大で数キロバイトである場合、read（2）は要求されたものよりも少ない値を返すことができますか？
いくつかの推測：
ファイルに残っているバイト数がnbyte未満の場合、 read()要求がシグナルによって中断された場合、またはファイルがパイプ、FIFO、または特殊ファイルであり、バイト数がnbyte未満の場合、返される値は nbyte 未満になることがあります。読み取りにすぐに利用できるnbyteバイト。
ディスクベースのファイルシステムは通常、割り込み不可の読み取りを使用します。つまり、読み取り操作は通常、シグナルによって中断されることはありません。ネットワークベースのファイルシステムは、割り込み可能な読み取りを使用する場合があり、部分的なデータを返すか、データを返さないことがあります。(NFS の場合、これはintrマウント オプションを使用して構成できます。) また、タイムアウトを実装することもあります。
/some/arbitrary/file/path でさえ FIFO または特別なファイルを参照している可能性があるため、通常のファイルだと思っていたものはそうではない可能性があることに注意してください。したがって、可能性が低い場合でも、部分的な読み取りを処理することをお勧めします。
私は尋ねなければなりません：「なぜあなたは理由を気にするのですか？」readが要求された量より少ないバイト数を返すことができる場合（あなたが指摘するように、それは確かに可能です）、なぜあなたはその状況に対処したくないのですか？
受信したシグナルは、まだ1バイトを読み取っていない場合にのみread（）を失敗させます。それ以外の場合は、部分的なデータを返します。
そして、他の状況では、代替ファイルシステムが実際に短い読み取りを返す可能性があると思います。たとえば、ネットワークベースのファイルシステムを短い読み取り（=頻繁に使用する）でネットワークソケットのように動作させることは、（私にとっては）ある程度意味があります。
それが実際に読んでいるファイルである場合、ファイルの終わりの前の最後の読み取りとして短い読み取りを取得できます。
ただし、一般的には、すべての読み取りが短い読み取りであるかのように振る舞うのが最善です。読み取っているものがファイルではなくパイプまたは入力デバイス (stdin) である場合、バッファーが現在入力バッファーにあるものよりも大きい場合はいつでも短い読み取りを取得できます。
よくわかりませんが、OSのページキャッシュのページが不足している場合にこの状況が発生する可能性があります。その場合、フラッシュスレッドが呼び出されることを提案できますが、それはI/Oスケジューラーで使用されるヒューリスティックに依存します。この状況では、読み取りで返されるバイト数が少なくなる可能性があります。