システムのディスクへのアトミックな書き込みのサイズはどれくらいですか？

ドキュメントでディレクティブ、nginxのドキュメントは言いますaccess_log

バッファサイズは、ディスクファイルへのアトミックな書き込みのサイズを超えてはなりません。

システムでこのサイズを確認するにはどうすればよいですか？

決して遅くないより良い:)

簡単な答えは次のとおりです。「カーネルバージョンが3.14以降の場合、2,147,479,552バイト」

詳細な回答：

私が理解している限り、それは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セクションXSI 2.9.7（「通常のファイル操作とのスレッドの相互作用」）によると、

次のすべての関数は、通常のファイルまたはシンボリックリンクを操作するときに、POSIX.1-2008で指定された効果の中で互いにアトミックである必要があります。...

続いてリストされるAPIの中には、write（）とwritev（2）があります。また、スレッド（およびプロセス）全体でアトミックである必要がある影響には、ファイルオフセットの更新があります。ただし、バージョン3.14より前のLinuxでは、これは当てはまりませんでした。開いているファイルの説明（open（2）を参照）を共有する2つのプロセスが同時にwrite（）（またはwritev（2））を実行すると、I / O操作は、ファイルオフセットの更新に関してアトミックではなかったため、2つのプロセスによって出力されたデータのブロックが（誤って）オーバーラップする可能性があります。この問題はLinux 3.14で修正されました。

このスーパーユーザーの回答には、アトミックな書き込みサイズが明確に定義されています。

これは、少なくともハードウェアセクターのサイズと同じです。これは、アトミックな読み取り/書き込みサイズです。