mieux vaut tard que jamais :)
la réponse rapide est :"2 147 479 552 octets, si la version du noyau est 3.14 ou plus récente"
réponse détaillée :
Autant que je sache, il s'agit d'écrire un appel système :
http://man7.org/linux/man-pages/man2/write.2.html
1) tous les systèmes POSIX (linux, bsd, tous unix) sont garantis pour pouvoir écrire jusqu'à MAX_SSIZE octets
Selon POSIX.1, si count est supérieur à SSIZE_MAX, le résultat est défini par l'implémentation ; voir les NOTES pour la limite supérieure sous Linux.
# getconf SSIZE_MAX
32767
2) linux est garanti capable d'écrire jusqu'à 1,99 Gio (et son fonctionnement atomique pour la version 3.14 du noyau Linux et les versions ultérieures)
Sous Linux, write() (et les appels système similaires) transférera au maximum 0x7ffff000 (2 147 479 552) octets, renvoyant le nombre d'octets réellement transférés. (Ceci est vrai sur les systèmes 32 bits et 64 bits.)
Mais c'est un fonctionnement atomique équitable uniquement à partir du noyau Linux 3.14
Selon POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("ThreadInteractions with Regular File Operations") :
Toutes les fonctions suivantes doivent être atomiques les unes par rapport aux autres dans les effets spécifiés dans POSIX.1-2008 lorsqu'elles opèrent sur des fichiers normaux ou des liens symboliques :...
Parmi les API listées ci-dessous figurent write() et writev(2). Et parmi les effets qui devraient être atomiques à travers les threads (et les processus), il y a les mises à jour de l'offset du fichier. Cependant, sous Linux avant la version 3.14, ce n'était pas le cas :si deux processus qui partagent une description de fichier ouverte (voir open(2)) effectuent un write() (ou writev(2)) en même temps, alors les E/S les opérations n'étaient pas atomiques en ce qui concerne la mise à jour de l'offset du fichier, avec pour résultat que les blocs de données produits par les deux processus pouvaient (incorrectement) se chevaucher. Ce problème a été corrigé dans Linux 3.14.