besser spät als nie :)
Die schnelle Antwort lautet:"2.147.479.552 Bytes, wenn die Kernel-Version 3.14 oder neuer ist"
ausführliche Antwort:
Soweit ich weiß, geht es darum, Syscall zu schreiben:
http://man7.org/linux/man-pages/man2/write.2.html
1) Alle POSIX-Systeme ( Linux, BSD, alle Unix ) sind garantiert in der Lage, bis zu MAX_SSIZE Bytes zu schreiben
Wenn count größer als SSIZE_MAX ist, ist das Ergebnis gemäß POSIX.1 implementierungsdefiniert; siehe ANMERKUNGEN für die Obergrenze unter Linux.
# getconf SSIZE_MAX
32767
2) Linux kann garantiert bis zu 1,99 GiB schreiben (und es ist atomarer Betrieb für Linux-Kernel-Version 3.14 und neuer)
Unter Linux überträgt write() (und ähnliche Systemaufrufe) höchstens 0x7ffff000 (2.147.479.552) Bytes und gibt die Anzahl der tatsächlich übertragenen Bytes zurück. (Dies gilt sowohl für 32-Bit- als auch für 64-Bit-Systeme.)
Aber es ist nur ab Linux-Kernel 3.14
ein fairer atomarer BetriebGemäß POSIX.1-2008/SUSv4 Abschnitt XSI 2.9.7 ("ThreadInteractions with Regular File Operations"):
Alle der folgenden Funktionen sollen bezüglich der in POSIX.1-2008 spezifizierten Wirkungen atomar sein, wenn sie auf regulären Dateien oder symbolischen Links operieren:...
Zu den nachfolgend aufgelisteten APIs gehören write() und writev(2). Und zu den Effekten, die über Threads (und Prozesse) hinweg atomar sein sollten, gehören Aktualisierungen des Datei-Offsets. Unter Linux vor Version 3.14 war dies jedoch nicht der Fall:Wenn zwei Prozesse, die sich eine offene Dateibeschreibung teilen (siehe open(2)), gleichzeitig ein write() (oder writev(2)) ausführen, dann wird die I/O Die Operationen waren nicht atomar in Bezug auf die Aktualisierung des Datei-Offsets, mit dem Ergebnis, dass sich die von den beiden Prozessen ausgegebenen Datenblöcke (fälschlicherweise) überlappen konnten. Dieses Problem wurde in Linux 3.14 behoben.