La compatibilidad con 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 .
Detalles
Tradicionalmente, muchos sistemas operativos y sus implementaciones de sistemas de archivos subyacentes usaban números enteros de 32 bits para representar tamaños y posiciones de archivos . En consecuencia, ningún archivo puede tener un tamaño superior a 2 32 - 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 31 - 1 bytes (2 GiB - 1). Los archivos que eran demasiado grandes para que los manejaran los sistemas operativos de 32 bits se conocieron como archivos grandes .
Si bien el límite era bastante aceptable en un momento en que los discos duros eran más pequeños, el aumento general de la capacidad de almacenamiento combinado con un mayor uso de archivos de servidor y escritorio, especialmente para archivos de base de datos y 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 de la industria conocida como Large File Summit para admitir archivos grandes en POSIX (en ese momento, Windows NT ya admitía archivos grandes en NTFS), un trasfondo obvio de "LFS". A la cumbre se le encomendó la tarea de definir una forma estandarizada de cambiar a números de 64 bits para representar el tamaño de los 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 con frecuencia 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 en el sistema de archivos. Por ejemplo, el sistema de archivos FAT32 de Microsoft Windows no admite archivos de más de 4 GiB − 1; hay que utilizar NTFS o exFAT en su lugar.
- Para admitir la compatibilidad binaria con aplicaciones antiguas , las interfaces del sistema operativo debían conservar el uso de tamaños de archivo de 32 bits y las nuevas interfaces debían diseñarse específicamente para admitir archivos grandes.
- Para admitir la escritura de código portátil que hace uso de LFS siempre que sea posible, los autores de bibliotecas estándar de C idearon mecanismos que, dependiendo de las constantes del preprocesador , redefinieron de manera transparente las funciones a las de 64 bits con reconocimiento de archivos grandes.
- Muchas interfaces antiguas, especialmente las basadas en C , especificaban explícitamente tipos de argumentos de una manera que no permitía una transición directa o transparente a tipos de 64 bits. Por ejemplo, C funciona
fseek
yftell
opera en posiciones de archivo de tipolong int
, que normalmente tiene 32 bits de ancho en plataformas de 32 bits, y no se puede agrandar sin sacrificar la compatibilidad con versiones anteriores. (Esto se resolvió mediante la introducción de nuevas funcionesfseeko
yftello
en POSIX . [2] En máquinas Windows, bajo Visual C ++, se utilizan funciones_fseeki64
y_ftelli64
).
Adopción
El uso de la API de archivos grandes en programas de 32 bits había sido incompleto durante mucho tiempo. Un análisis mostró en 2002 que muchas bibliotecas base de sistemas operativos todavía se enviaban sin soporte para archivos grandes, lo que limitaba las aplicaciones que las usaban. [3] La biblioteca zlib muy utilizada comenzó a admitir archivos grandes de 64 bits en una plataforma de 32 bits no antes de 2006. [4]
El problema desapareció lentamente con la PC y las estaciones de trabajo pasando por completo a la informática de 64 bits . Microsoft Windows Server 2008 ha sido la última versión de servidor que se envió en 32 bits. [5] Redhat Enterprise Linux 7 se publicó en 2014 solo como un sistema operativo de 64 bits. [6] Ubuntu Linux dejó de ofrecer una variante de 32 bits en 2019. [7] Nvidia dejó de desarrollar controladores de 32 bits en 2018 y dejó de entregar actualizaciones después de enero de 2019. [8] Apple dejó de desarrollar versiones de Mac OS de 32 bits en 2018. entregando macOS Mojave solo como un sistema operativo de 64 bits. [9] No se conoce el final de la vida útil de Windows 10 en el escritorio 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 ejecutaron en computadoras antiguas integradas en el i386 arquitectura. [10]
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, [11] lo que permite descontinuar el soporte de 32 bits para Android más adelante. [12] 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 adecuada de 64 bits del sistema operativo. [13] [12] Apple había hecho un cambio en el año antes de comenzar a producir el Apple A7 de 64 bits en 2013. Google comenzó a ofrecer el entorno de desarrollo para Linux solo en 64 bits en 2015. [14] En mayo de 2019, el la proporción de versiones de Android por debajo de 5 había caído al diez por ciento. [15] A medida que los desarrolladores de aplicaciones se concentran en una única variante de compilación , muchos fabricantes comenzaron a requerir Android 5 como versión mínima a mediados de 2019, por ejemplo, Niantic. [16] Posteriormente, las versiones de 32 bits fueron difíciles de conseguir. [17]
A excepción de los sistemas integrados con sus programas especiales, la consideración de la compatibilidad con archivos grandes variables se vuelve obsoleta en el código del programa después de 2020.
Problemas relacionados
El problema del año 2038 es bien conocido por otro caso en el que un "largo" de 32 bits en plataformas de 32 bits generará problemas. Al igual que la limitación de archivos grandes, se volverá obsoleta cuando los sistemas se muevan solo a 64 bits. Mientras tanto, se introdujo una marca de tiempo de 64 bits. En la API de Win32, es visible en las funciones que tienen un sufijo "64" junto al sufijo "32" anterior. Cuando se agregó compatibilidad con archivos grandes a la API de Win32, las funciones tienen un sufijo "i64" adicional que a veces hace cuatro combinaciones (findfirst32, findfirst64, findfirst32i64, findfirst64i32). [18] 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 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 usa 64 bits para los números LBA ( dirección de bloque lógico ). En sistemas operativos similares a Unix, también requería ampliar los números de inodo que se utilizan en algunas funciones (stat64, setrlimit64). El kernel de Linux lo introdujo en 2001, lo que condujo a la versión 2.4, que fue recogida por glibc en ese año. [19] Dado que el soporte para archivos grandes y el soporte para discos grandes se introdujeron al mismo tiempo, la biblioteca GNU C exporta estructuras de inodo de 64 bits en arquitecturas de 32 bits al mismo tiempo que se activa la API Unix LFS en el código del programa. [20]
Cuando el kernel se movió a inodos de 64 bits, el sistema de archivos ext3 los usó internamente en el controlador en 2001. Sin embargo, el formato de inodo en el medio de almacenamiento estaba atascado en números de 32 bits. [19] A medida que los dispositivos de almacenamiento masivo se movieron 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. [19] 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 exabytes. [21] [22] 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 pronosticaban SSD de 100 TiB para 2020. [23]
Ver también
- Límite de 2 GB
- RF64 : soporte de 64 bits para archivos de audio BWF WAV
- Comparación de la compatibilidad con archivos grandes en editores de texto
- FAT32 + [24]
- Tamaño del archivo
- Soporte de nombre de archivo largo (LFN)
- Problema del año 2038
Referencias
- ^ Grupo de sistema operativo Solaris (marzo de 1996). "Archivos grandes en Solaris: un informe técnico" (PDF) . Sun Microsystems . Archivado desde el original (PDF) el 28 de febrero de 2007.
- ^ "Adición de compatibilidad con archivos grandes a la especificación única de UNIX" . X / Grupo de trabajo de base abierta. 1996-08-14 . Consultado el 10 de septiembre de 2006 .
- ^ http://ac-archive.sourceforge.net/largefile/distros.html
- ^ https://www.zlib.net/ChangeLog.txt
- ^ Kolokythas, Panagiotis (28 de mayo de 2007). "Windows Server 2008: Microsofts letztes 32-Bit-Betriebssystem für Server" (en alemán). PC Welt .
- ^ "¿Las aplicaciones de 32 bits son compatibles con RHEL 7 o versiones posteriores?" . Red Hat . Febrero 2014.
- ^ Cooke, Will (2 de junio de 2019). "Paquetes Intel de 32 bits en Ubuntu desde 19.10 en adelante" . Canónico.
- ^ Addams, Matthew (12 de abril de 2018). "Nvidia suspende el soporte para plataformas Windows de 32 bits" . Informe de Windows.
- ^ Silver, Steven (5 de junio de 2018). "Mojave es la última versión de macOS de Apple que admite aplicaciones de 32 bits" . Apple Insider .
- ^ "Der Support für Windows 7 finalizado el 14 de enero de 2020" (en alemán). Microsoft . Consultado el 9 de febrero de 2020 .
- ^ Sebayang, Andreas (17 de enero de 2019). "Auf dem Weg zu reinen 64-Bit-Android-Apps" (en alemán). Golem.
- ^ a b mw (17 de enero de 2019). "Google kündigt Ende von 32-Bit-Android-Apps per 2021 an" (en alemán). IT Magazin.
- ^ "Android de 64 bits: Diese Prozessoren gibt es, diese Veränderungen kommen" (en alemán). Usuario de Android. 2014-08-26.
- ^ "Platform-tools 23.1.0 Linux cambió a 64 bits sin previo aviso" . Rastreador público de Android. 2015-12-11.
Resulta que el contenido de android-sdk-linux / platform-tools es ELF de 32 bits en 23.0.1 pero ELF de 64 bits en 23.1_rc1 y 23.1.0. […] Configuré ANDROID_EMULATOR_FORCE_32BIT = true […] 23.0.1 es la última compilación de Linux de 32 bits.
- ^ Tenzer, F. (14 de noviembre de 2019). "Anteile der verschiedenen Android-Versionen an allen Geräten mit Android OS weltweit im Zeitraum 01. bis 07. Mai 2019" (en alemán). Statista.
- ^ Del Favero, Elia (10 de junio de 2019). "Ingress und Pokémon Go brauchen bald mindestens Android 5" .
- ^ "¿Por qué la versión de 32 bits 0.159.0 apk aún no está disponible?" . TheSilphRoad / . Reddit. Diciembre de 2019.
- ^ "Referencia de la biblioteca en tiempo de ejecución de C (CRT): findfirst" . Microsoft . Consultado el 17 de febrero de 2020 .
- ^ a b c Jaeger, Andreas (15 de febrero de 2015). "Soporte de archivos grandes en Linux" . SuSE GmbH .
- ^ linux / bits / stat.h: / * Tenga en cuenta que stat64 tiene la misma forma que stat para x86-64. * /
- ^ Rutter, MJ "El problema del inodo de 64 bits" . Consultado el 10 de febrero de 2020 .
- ^ "Ext4 Howto" . kernel.org . 2019-02-11.
Aunque los sistemas de archivos muy grandes están en la lista de características de ext4, e2fsprogs actual todavía limita el tamaño del sistema de archivos a 2 ^ 32 bloques (16TiB para un sistema de archivos de bloques de 4KiB). Permitir sistemas de archivos mayores de 16T es una de las siguientes características de alta prioridad que se completarán para ext4.
- ^ Scherer, Thomas (15 de agosto de 2016). "Samsungs 32-TB-SSD: Der Anfang vom Ende der Festplatte" (en alemán). Elektor .
- ^ Kuhnt, Udo; Georgiev, Luchezar I .; Davis, Jeremy (2007). "FAT + borrador de revisión 2" (FATPLUS.TXT) (2 ed.) . Consultado el 5 de agosto de 2015 .
enlaces externos
- Jaeger, Andreas (15 de febrero de 2005). "Soporte de archivos grandes en Linux" . SuSE GmbH . Consultado el 10 de septiembre de 2006 .