Compatibilidad con archivos grandes

El soporte para archivos grandes ( LFS , por sus siglas en inglés) es el término que se aplica con frecuencia a la capacidad de crear archivos de más de 2 o 4 GiB en sistemas de archivos de 32 bits . 

Tradicionalmente, muchos sistemas operativos y sus implementaciones de sistemas de archivos subyacentes utilizaban enteros de 32 bits para representar el tamaño y la posición de los archivos . En consecuencia, ningún archivo podía ser mayor que ^2³² − 1 bytes (4 GiB − 1). En muchas implementaciones, el problema se agravaba al tratar los tamaños como números con signo , lo que reducía aún más el límite a 2³¹ ⁻ 1 bytes (2 GiB − 1). Los archivos demasiado grandes para ser gestionados por sistemas operativos de 32 bits se conocían como archivos grandes .

Si bien el límite era bastante aceptable en una época en la que los discos duros eran más pequeños, el aumento general de la capacidad de almacenamiento, combinado con el mayor uso de archivos en servidores y ordenadores de escritorio, especialmente para archivos de bases de datos y multimedia , generó una intensa presión sobre los proveedores de sistemas operativos para que superaran dicha limitación.

En 1996, varios proveedores respondieron creando una iniciativa industrial conocida como Large File Summit para admitir archivos grandes en POSIX (en ese momento Windows NT ya admitía archivos grandes en NTFS), un acrónimo inverso obvio de "LFS". La cumbre tenía la tarea de definir una forma estandarizada de cambiar a números de 64 bits para representar los tamaños de los archivos. ^{[ 1 ]}

Este cambio provocó problemas de implementación y requirió modificaciones de diseño, cuyas consecuencias aún se pueden observar:

• El cambio a tamaños de archivo de 64 bits frecuentemente requería cambios incompatibles en el diseño del sistema de archivos, lo que significaba que la compatibilidad con archivos grandes a veces requería un cambio de sistema de archivos. Por ejemplo, el sistema de archivos FAT32 no admite archivos mayores de 4  GiB−1 (con aplicaciones antiguas incluso solo 2  GiB−1); la variante FAT32+ sí admite archivos más grandes (hasta 256  GiB−1), pero (hasta ahora) solo es compatible con algunas versiones de DR-DOS , ^{[ 2 ] [ 3 ]} por lo que los usuarios de Microsoft Windows tienen que usar NTFS o exFAT en su lugar.
• Para garantizar la compatibilidad binaria con las aplicaciones antiguas, las interfaces del sistema operativo tuvieron que mantener el uso de tamaños de archivo de 32 bits y se tuvieron que diseñar nuevas interfaces específicamente para admitir archivos grandes.
• Para facilitar la escritura de código portable que utilice LFS siempre que sea posible, los autores de la biblioteca estándar de C idearon mecanismos que, dependiendo de las constantes del preprocesador , redefinían de forma transparente las funciones para adaptarlas a las que admiten archivos grandes de 64 bits.
• Muchas interfaces antiguas, especialmente las basadas en C , especificaban explícitamente los tipos de argumentos de una manera que no permitía una transición directa o transparente a tipos de 64 bits. Por ejemplo, las funciones de C fseeky ftelloperan en posiciones de archivo de tipo long int, que normalmente tiene 32 bits de ancho en plataformas de 32 bits, y no se puede aumentar sin sacrificar la compatibilidad con versiones anteriores. (Esto se resolvió introduciendo nuevas funciones fseekoy ftelloen POSIX . ^{[ 4 ]} En máquinas Windows, bajo Visual C++, se utilizan las funciones _fseeki64y _ftelli64).

El uso de la API de archivos grandes en programas de 32 bits había sido incompleto durante mucho tiempo. Un análisis realizado en 2002 mostró que muchas bibliotecas base de sistemas operativos aún se distribuían sin soporte para archivos grandes, lo que limitaba las aplicaciones que las utilizaban. ^{[ 5 ]} La muy utilizada biblioteca zlib comenzó a admitir archivos grandes de 64 bits en plataformas de 32 bits no hasta 2006. ^{[ 6 ]}

El problema desapareció lentamente con las PC y estaciones de trabajo migrando completamente a la computación de 64 bits . Microsoft Windows Server 2008 ha sido la última versión de servidor que se ha distribuido en 32 bits. ^{[ 7 ]} Red Hat Enterprise Linux 7 se publicó en 2014 solo como un sistema operativo de 64 bits. ^{[ 8 ]} Ubuntu Linux dejó de distribuir una variante de 32 bits en 2019. ^{[ 9 ]} Nvidia dejó de desarrollar controladores de 32 bits en 2018 y de distribuir actualizaciones después de enero de 2019. ^{[ 10 ]} Apple dejó de desarrollar versiones de Mac OS de 32 bits en 2018, distribuyendo macOS Mojave solo como un sistema operativo de 64 bits. ^{[ 11 ]} El fin del ciclo de vida de Windows 10 se ha establecido en 2025 en el escritorio, lo que está relacionado con las últimas actualizaciones de sistemas antiguos como Windows 7 y Windows 8 en enero de 2020, ya que algunos de esos sistemas se ejecutaban en computadoras antiguas construidas en la arquitectura i386. ^{[ 12 ]} Sin embargo, Windows 11 se distribuirá únicamente como un sistema operativo de 64 bits desde su primera versión en 2021.

Un desarrollo similar se puede ver en el área móvil. Google requirió admitir versiones de 64 bits de aplicaciones en su tienda de aplicaciones para agosto de 2019, ^{[ 13 ]} lo que permite descontinuar el soporte de 32 bits para Android más adelante. ^{[ 14 ]} El cambio hacia 64 bits comenzó en 2014 cuando todos los nuevos procesadores fueron diseñados para una arquitectura de 64 bits y Android 5 ("Lollipop") se publicó ese año proporcionando una variante de 64 bits adecuada del sistema operativo. ^{[ 15 ] [ 14 ]} Apple había hecho el cambio el año anterior a comenzar a producir el Apple A7 de 64 bits para 2013. Google comenzó a entregar el entorno de desarrollo para Linux solo en 64 bits para 2015. ^{[ 16 ]} En mayo de 2019 la proporción de versiones de Android inferiores a 5 había caído al diez por ciento. ^{[ 17 ]} A medida que los desarrolladores de aplicaciones se concentran en una única variante de compilación , muchos fabricantes comenzaron a exigir Android 5 como versión mínima a mediados de 2019, por ejemplo Niantic. ^{[ 18 ]} Posteriormente, las versiones de 32 bits fueron difíciles de conseguir. ^{[ 19 ]}

Salvo en el caso de los sistemas embebidos con sus programas especiales, la consideración de la compatibilidad con archivos grandes se vuelve obsoleta en el código de programación después de 2020.

El problema del año 2038 es bien conocido por otro caso donde un "long" de 32 bits en plataformas de 32 bits provocará problemas. Al igual que la limitación de archivos grandes, se volverá obsoleto cuando los sistemas migren a solo 64 bits. Mientras tanto, se introdujo una marca de tiempo de 64 bits. En la API de Win32 es visible en funciones que tienen un sufijo "64" junto con el sufijo anterior "32". Cuando se agregó soporte para archivos grandes a la API de Win32, ha dado lugar a funciones con un sufijo adicional "i64" que a veces hace cuatro combinaciones. (findfirst32, findfirst64, findfirst32i64, findfirst64i32). ^{[ 20 ]} En comparación, la API de UNIX98 introduce funciones con un sufijo "64" cuando se usa "_LARGEFILE64_SOURCE".

En relación con la API de archivos grandes, existe una limitación en el número de bloques para los medios de almacenamiento masivo . Con un tamaño común de 512 bytes por bloque de datos, la barrera resultante de los números de 32 bits se produjo más tarde. Cuando los discos duros alcanzaron un tamaño de 2 terabytes (alrededor de 2010), el registro de arranque maestro tuvo que ser reemplazado por la tabla de particiones GUID , que utiliza 64 bits para los números LBA ( dirección lógica de bloque ). En los sistemas operativos tipo Unix, también fue necesario ampliar los números de inodo que se utilizan en algunas funciones (stat64, setrlimit64). El kernel de Linux introdujo esto en 2001, dando lugar a la versión 2.4, que fue adoptada por glibc ese mismo año. ^{[ 21 ]} Dado que la compatibilidad con archivos grandes y discos grandes se introdujo al mismo tiempo, la biblioteca C de GNU exporta estructuras de inodo de 64 bits en arquitecturas de 32 bits al mismo tiempo que se activa la API LFS de Unix en el código del programa. ^{[ 22 ]}

Cuando el kernel pasó a inodos de 64 bits, el sistema de archivos ext3 los usó internamente en el controlador hacia 2001. Sin embargo, el formato de inodo en el medio de almacenamiento en sí se quedó en números de 32 bits. ^{[ 21 ]} A medida que los dispositivos de almacenamiento masivo pasaron al formato avanzado de 4 kilobytes por bloque, el límite real de ese formato de sistema de archivos es de 8 o 16 terabytes. ^{[ 21 ]} El manejo de particiones de disco más grandes requiere el uso de un sistema de archivos diferente como XFS , que fue diseñado con inodos de 64 bits desde el principio, lo que permite archivos y particiones de exabytes. ^{[ 23 ] [ 24 ]} Las primeras unidades de disco magnético de 16 terabytes se entregaron a mediados de 2019. Las unidades de estado sólido con 32 TiB para centros de datos estaban disponibles ya en 2016, y algunos fabricantes pronosticaron SSD de 100 TiB para 2020. ^{[ 25 ]}

• Límite de 2 GB
• RF64 : compatibilidad con 64 bits para archivos de audio WAV BWF.
• Comparación de la compatibilidad con archivos grandes en los editores de texto
• FAT32+
• Tamaño del archivo
• Archivo que abarca
• Compatibilidad con nombres de archivo largos (LFN)
• Problema del año 2038

• Jaeger, Andreas (15 de febrero de 2005). "Soporte para archivos grandes en Linux" . SuSE GmbH . Consultado el 10 de septiembre de 2006 .