Soporte para archivos de gran tamaño

El soporte de archivos grandes ( LFS ) 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 números enteros de 32 bits para representar los tamaños y las posiciones de los archivos . En consecuencia, ningún archivo podía tener un tamaño superior a 2 ³² − 1 bytes (4 GiB − 1). En muchas implementaciones, el problema se agravó al tratar los tamaños como números con signo , lo que redujo aún más el límite a 2 ³¹ − 1 bytes (2 GiB − 1). Los archivos que eran demasiado grandes para que los manejaran los sistemas operativos de 32 bits pasaron a conocerse 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 en la capacidad de almacenamiento combinado con un mayor uso de archivos de servidores y escritorios, especialmente para bases de datos y archivos multimedia , generó una intensa presión para que los proveedores de sistemas operativos superaran la limitación.

En 1996, varios proveedores respondieron formando 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 obvio de "LFS". La cumbre tenía como objetivo definir una forma estandarizada de cambiar a números de 64 bits para representar tamaños de archivos. ^[1]

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

• El cambio a tamaños de archivo de 64 bits requirió frecuentemente 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 del sistema de archivos. Por ejemplo, el sistema de archivos FAT32 no admite archivos mayores a 4 GiB−1 (con aplicaciones más 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 soportar la compatibilidad binaria con aplicaciones antiguas , las interfaces del sistema operativo tuvieron que conservar el uso de tamaños de archivo de 32 bits y las nuevas interfaces tuvieron que diseñarse específicamente para soportar archivos grandes.
• Para respaldar la escritura de código portable que haga uso de LFS cuando sea posible, los autores de la biblioteca estándar de C idearon mecanismos que, dependiendo de las constantes del preprocesador , redefinieron de manera transparente las funciones para 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 los tipos de 64 bits. Por ejemplo, las funciones fseeky de C ftelloperan en posiciones de archivo de tipo long int, que normalmente tiene un ancho de 32 bits en plataformas de 32 bits, y no se puede hacer más grande sin sacrificar la compatibilidad con versiones anteriores. (Esto se resolvió introduciendo nuevas funciones fseekoy ftelloen POSIX . ^[4] En las 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 ha sido incompleto durante mucho tiempo. Un análisis realizado en 2002 mostró que muchas bibliotecas base de sistemas operativos aún se entregaban sin compatibilidad con archivos grandes, lo que limitaba las aplicaciones que las usaban. ^{[5] La biblioteca} zlib, muy utilizada, comenzó a admitir archivos grandes de 64 bits en plataformas de 32 bits recién en 2006. ^[6]

El problema desapareció lentamente con las PC y estaciones de trabajo moviéndose completamente a la computación de 64 bits . Microsoft Windows Server 2008 ha sido la última versión de servidor que se envió en 32 bits. ^[7] Redhat Enterprise Linux 7 se publicó en 2014 solo como un sistema operativo de 64 bits. ^[8] Ubuntu Linux dejó de entregar una variante de 32 bits en 2019. ^[9] Nvidia dejó de desarrollar controladores de 32 bits en 2018 y entregar actualizaciones después de enero de 2019. ^[10] Apple dejó de desarrollar versiones de Mac OS de 32 bits en 2018 entregando macOS Mojave solo como un sistema operativo de 64 bits. ^[11] El final de la vida útil de Windows 10 se ha establecido para 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 enviará solo 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ó soportar 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 tarde. ^[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ó en ese año proporcionando una variante adecuada de 64 bits del sistema operativo. ^{[15] [14]} Apple había hecho el cambio en el año antes de comenzar a producir el Apple A7 de 64 bits en 2013. Google comenzó a entregar el entorno de desarrollo para Linux solo en 64 bits en 2015. ^[16] En mayo de 2019, la proporción de versiones de Android por debajo de 5 había caído al diez por ciento. ^[17] Como los desarrolladores de aplicaciones se concentran en una sola variante de compilación , muchos fabricantes comenzaron a requerir Android 5 como la versión mínima a mediados de 2019, por ejemplo Niantic. ^[18] Posteriormente las versiones de 32 bits fueron difíciles de conseguir. ^[19]

A excepción de los sistemas integrados con sus programas especiales, la consideración de compatibilidad variable con archivos de gran tamaño queda obsoleta en el código del programa después de 2020.

El problema del año 2038 es bien conocido por otro caso en el que un "long" de 32 bits en plataformas de 32 bits provocará problemas. Al igual que la limitación de archivos grandes, quedará obsoleto cuando los sistemas pasen a funcionar sólo con 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 "32" anterior. Cuando se agregó soporte para archivos grandes a la API de Win32, esto llevó a que las funciones tuvieran un sufijo "i64" adicional que a veces da lugar a cuatro combinaciones (findfirst32, findfirst64, findfirst32i64, findfirst64i32). ^[20] En comparación, la API de UNIX98 introduce funciones con un sufijo "64" cuando se utiliza "_LARGEFILE64_SOURCE".

En relación con la API de archivos grandes, existe una limitación de los números de bloque 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 las unidades de disco duro 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 de bloque lógico ). En los sistemas operativos tipo Unix también se requirió aumentar los números de inodo que se utilizan en algunas funciones (stat64, setrlimit64). El núcleo de Linux introdujo eso en 2001, lo que llevó a la versión 2.4 que fue adoptada por la glibc ese año. ^[21] Como el soporte para archivos grandes y el soporte para discos grandes se introdujeron 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 los inodos de 64 bits, el sistema de archivos ext3 los utilizó internamente en el controlador en 2001. Sin embargo, el formato de inodo en el propio medio de almacenamiento se quedó estancado 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 está en 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 pronostican SSD de 100 TiB para 2020. ^[25]

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

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