mejor tarde que nunca :)
la respuesta rápida es: "2,147,479,552 bytes, si la versión del kernel es 3.14 o más nueva"
respuesta detallada:
Por lo que yo entiendo, se trata de escribir syscall:
http://man7.org/linux/man-pages/man2/write.2.html
1) cualquier sistema POSIX (linux, bsd, todos unix) está garantizado para poder escribir hasta MAX_SSIZE bytes
Según POSIX.1, si el recuento es mayor que SSIZE_MAX, el resultado está definido por la implementación; vea las NOTAS para el límite superior en Linux.
# getconf SSIZE_MAX
32767
2) Linux garantiza poder escribir hasta 1.99 GiB (y es una operación atómica para Linux kernel versión 3.14 y posteriores)
En Linux, write () (y llamadas de 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 los sistemas de 32 bits como en los 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í en los efectos especificados en POSIX.1-2008 cuando operan en archivos regulares o enlaces simbólicos: ...
Entre las API que se enumeran posteriormente se encuentran write () y writev (2). Y entre los efectos que deberían ser atómicos en los 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 el I Las operaciones / O no fueron atómicas con respecto a la actualización del desplazamiento del archivo, con el resultado de que los bloques de salida de datos de los dos procesos podrían (incorrectamente) solaparse. Este problema se solucionó en Linux 3.14.