meglio tardi che mai :)
la risposta rapida è:"2.147.479.552 byte, se la versione del kernel è 3.14 o successiva"
risposta dettagliata:
Per quanto ho capito, si tratta di scrivere syscall:
http://man7.org/linux/man-pages/man2/write.2.html
1) tutti i sistemi POSIX ( linux, bsd, tutti unix ) sono garantiti per essere in grado di scrivere fino a MAX_SSIZE byte
Secondo POSIX.1, se count è maggiore di SSIZE_MAX, il risultato è definito dall'implementazione; vedi NOTE per il limite massimo su Linux.
# getconf SSIZE_MAX
32767
2) Linux garantito per essere in grado di scrivere fino a 1,99 GiB (ed è un'operazione atomica per la versione del kernel Linux 3.14 e successive)
Su Linux, write() (e chiamate di sistema simili) trasferirà al massimo 0x7ffff000 (2.147.479.552) byte, restituendo il numero di byte effettivamente trasferiti. (Questo vale sia per i sistemi a 32 bit che per quelli a 64 bit.)
Ma è un'operazione atomica corretta solo dal kernel Linux 3.14
Secondo POSIX.1-2008/SUSv4 Sezione XSI 2.9.7 ("ThreadInteractions with Regular File Operations"):
Tutte le seguenti funzioni devono essere atomiche l'una rispetto all'altra negli effetti specificati in POSIX.1-2008 quando operano su file regolari o collegamenti simbolici:...
Tra le API successivamente elencate ci sono write() e writev(2). E tra gli effetti che dovrebbero essere atomici tra thread (e processi) vi sono gli aggiornamenti dell'offset del file. Tuttavia, su Linux prima della versione 3.14, non era così:se due processi che condividono una descrizione di un file aperto (vedi open(2)) eseguono un write() (o writev(2)) contemporaneamente, allora l'I/O le operazioni non erano atomiche rispetto all'aggiornamento dell'offset del file, con il risultato che i blocchi di dati emessi dai due processi potevano (erroneamente) sovrapporsi. Questo problema è stato risolto in Linux 3.14.