mejor tarde que nunca :)
la respuesta rápida es:"2,147,479,552 bytes, si la versión del kernel es 3.14 o posterior"
respuesta detallada:
Según tengo entendido, se trata de escribir syscall:
http://man7.org/linux/man-pages/man2/write.2.html
1) Se garantiza que todos los sistemas POSIX (linux, bsd, todos los unix) podrán escribir hasta MAX_SSIZE bytes
De acuerdo con POSIX.1, si el recuento es mayor que SSIZE_MAX, el resultado está definido por la implementación; consulte las NOTAS para conocer el límite superior en Linux.
# getconf SSIZE_MAX
32767
2) Linux garantizado para poder escribir hasta 1,99 GiB (y es una operación atómica para la versión 3.14 del kernel de Linux y más reciente)
En Linux, write() (y llamadas al sistema similares) transferirán como máximo 0x7ffff000 (2,147,479,552) bytes, devolviendo el número de bytes realmente transferidos. (Esto es cierto tanto en sistemas de 32 bits como de 64 bits).
Pero es una operación atómica justa solo desde el kernel 3.14 de Linux
De acuerdo con POSIX.1-2008/SUSv4 Sección XSI 2.9.7 ("Interacciones de subprocesos con operaciones regulares de archivos"):
Todas las siguientes funciones serán atómicas entre sí a los efectos especificados en POSIX.1-2008 cuando operen sobre archivos regulares o enlaces simbólicos:...
Entre las API enumeradas posteriormente se encuentran write() y writev(2). Y entre los efectos que deberían ser atómicos entre subprocesos (y procesos) se encuentran las actualizaciones del desplazamiento del archivo. Sin embargo, en Linux antes de la versión 3.14, este no era el caso:si dos procesos que comparten una descripción de archivo abierto (ver open(2)) realizan una escritura() (o writev(2)) al mismo tiempo, entonces la E/S las operaciones no eran atómicas con respecto a la actualización del desplazamiento del archivo, con el resultado de que los bloques de datos generados por los dos procesos podrían (incorrectamente) superponerse. Este problema se solucionó en Linux 3.14.