遅刻しないよりはましだ :)
簡単な答えは:"2,147,479,552 バイト、カーネルのバージョンが 3.14 以降の場合"
詳細な回答:
私が理解している限り、それは write syscall に関するものです:
http://man7.org/linux/man-pages/man2/write.2.html
1) あらゆる POSIX システム (linux、bsd、すべての unix) は、最大 MAX_SSIZE バイト を書き込めることが保証されています。
<ブロック引用>POSIX.1 によると、count が SSIZE_MAX より大きい場合、結果は実装定義です。 Linux での上限については、注を参照してください。
# getconf SSIZE_MAX
32767
2) Linux は最大 1.99 GiB の書き込みが保証されています (Linux カーネル バージョン 3.14 以降ではアトミック操作です)
<ブロック引用>Linux では、write() (および同様のシステム コール) は最大で 0x7ffff000 (2,147,479,552) バイトを転送し、実際に転送されたバイト数を返します。 (これは 32 ビット システムと 64 ビット システムの両方に当てはまります。)
しかし、それは Linux カーネル 3.14 からのみの公正なアトミック操作です
<ブロック引用>POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("ThreadInteractions with Regular File Operations") によると:
<ブロック引用>次のすべての関数は、通常のファイルまたはシンボリック リンクで動作する場合、POSIX.1-2008 で指定された効果において相互にアトミックである必要があります:...
次にリストされている API には、write() と writev(2) があります。スレッド (およびプロセス) 全体でアトミックであるべき効果の 1 つに、ファイル オフセットの更新があります。ただし、バージョン 3.14 より前の Linux では、これは当てはまりません:open ファイル記述 (open(2) を参照) を共有する 2 つのプロセスが同時に write() (または writev(2)) を実行すると、I/O操作は、ファイル オフセットの更新に関してアトミックではなく、その結果、2 つのプロセスによって出力されたデータのブロックが (誤って) オーバーラップする可能性がありました。この問題は Linux 3.14 で修正されました。