Large File Support

Large File Support (englisch für „Unterstützung großer Dateien“) ist eine Eigenschaft von Betriebssystemen oder Dateisystemen, sehr große Dateien öffnen und bearbeiten zu können. Häufig gibt das verwendete System diesen Grenzwert vor, bei einigen (älteren) Linux-Versionen sind dies z. B. 2 GiB oder bei FAT32 4 GiB. Große Datenbanken auf Servern, Bildbearbeitung oder Videoschnitt benötigen aber häufig große Dateien (engl. Large Files), die deutlich umfangreicher sind, so dass eine solche Anwendung von einer kleinen Größenbeschränkung für Dateien nicht betroffen sein darf.

Beschreibung

Das Problem liegt bei den über Jahrzehnte sehr verbreiteten 32-Bit-Betriebssystemen in der Größenbeschränkung von Integer-Zahlen. Eine 32-Bit-Integer-Zahl kann nur Werte bis 2 GiB (mit Vorzeichen) oder 4 GiB (ohne Vorzeichen) darstellen. Zur Unterstützung sehr großer Dateien muss daher in 32-Bit-Programmen ein neuer Datentyp und zugehörige Betriebssystemfunktionen eingeführt werden, was ein Umschreiben alter Programme erforderlich macht. Ältere Versionen und insbesondere nicht mehr gewartete Programme können daher selbst bei Existenz eines Large File Support nur Dateien mit einer maximalen Größe von 2 oder 4 GiB verarbeiten.

Die Entwicklung einer API mit 64-Bit Eigenschaften kam durch die Entwicklung der Festplatten zustande, die Anfang der 1990er Jahre die Gigabyte-Grenze durchbrachen. Anschließend entwickelte Dateisysteme stellten sich darauf ein – darunter das FreeBSD UFS2, das Linux ext2 (1993) und Windows NTFS (1993). Die Funktionalität des Betriebssystemkerns wurde dabei in verschiedener Art an die Applikationen durchgereicht, bis man sich im Unix-Umfeld beim herstellerübergreifenden „Large File Summit“ von 1996 auf eine gemeinsame API einigte. Diese wurde mit Single UNIX Specification Version 2 (UNIX 98) festgeschrieben.

Die Arithmetik in den zugehörigen C Compilern wurde als neuer 64-Bit „long long“ Datentyp in C mit der Standardisierung für C99 (ab 1995) hinzugefügt. Dies folgte aus der Entwicklung der Betriebssysteme für 32-Bit-Architekturen zur Nutzung eines ILP32-Programmiermodells, bei der die traditionellen Datentypen „int“, „long“, „pointer“ jeweils 32-Bit lang sind. Die traditionellen Funktionen „ftell“ und „fseek“ waren damit auf 32 Bit beschränkt. Für Posix „ftello“ / „fseeko“ sowie Windows „_ftelli64“ / „_fseeki64“ führten die Hersteller einen 64-Bit-Datentyp ein – anfangs mit unterschiedlicher Benennung.

Umsetzung

Die Übernahme der LFS API in 32-Bit Programme blieb lange unvollständig. Eine Untersuchung aus dem Jahre 2002 zeigte, dass auch Basisbibliotheken des Betriebssystems noch ohne LFS Unterstützung ausgeliefert wurden, und damit indirekt zahlreiche Anwendungen beschränkten. Die vielgenutzte zlib Bibliothek unterstützte den 64-Bit Zusatz auf 32-Bit Plattformen erst ab 2006.

Im Bereich der PC/Workstations erledigte sich das Problem letztlich dadurch, dass nur noch 64-Bit-Architekturen eingesetzt wurden. Microsoft Windows Server 2008 war die letzte Server-Version, die in 32 Bit ausgeliefert wurde. Redhat Enterprise Linux 7 wurde bei der Erstveröffentlichung 2014 nur noch als 64-Bit Betriebssystem bereitgestellt. Das Ubuntu Linux stoppte 2019 die Auslieferung als 32-Bit Betriebssystem. Nvidia stoppte die Entwicklung von 32-Bit Treibern 2018 und liefert seit Januar 2019 auch keine Updates mehr. Mac OS von Apple stoppte 2018 die Entwicklung von 32-Bit, sodass macOS Mojave nur noch als 64-Bit Betriebssystem zur Verfügung steht. Mit Microsoft Windows 10 wird die 32-Bit Unterstützung auf dem Desktop noch bis 2025 gepflegt, da es Anfang 2020 überhaupt erst die letzten Altversionen (Windows-7, Windows-8) ersetzt hat, die teils noch auf i386 Architekturen eingesetzt wurden. Microsoft Windows 11 wird jedoch seit der Erstveröffentlichung 2021 nur als 64-Bit Betriebssystem bereitgestellt.

Im Bereich der mobilen Geräte fordert Google die native Unterstützung von 64-Bit durch Applikationen seit August 2019, sodass eine Abkündigung der 32-Bit Unterstützung in Android vorbereitet wird. Die Umstellung auf 64-Bit begann 2014, als alle neueren Prozessoren nur noch in 64-Bit angekündigt wurden, und mit Android 5 („Lollipop“) ein passendes Betriebssystem in diesem Jahr bereitgestellt wurde. Apple hatte die Umstellung schon vorher mit dem 64-Bit Apple A7 begonnen, der 2013 vorgestellt wurde. Google lieferte den Entwicklerarbeitsplatz unter Linux dann ab 2015 nur noch für 64-Bit aus. Im Mai 2019 lag die Verbreitung von Android-Versionen unterhalb 5 noch bei etwa zehn Prozent. Für den Google Play App Store wurde verfügt, dass ab August 2019 immer auch 64-Bit Versionen der Apps bereitgestellt werden müssen, ausgenommen davon waren Spiele, für die diese Anforderung ab August 2021 gilt. Da App-Entwickler sich auf ein Kompilat konzentrieren, haben viele Hersteller ab Mitte 2019 die Version 5 als Mindestversion angesetzt, beispielsweise Niantic. Eine 32-Bit Version war anschließend nur noch schwer erhältlich. Die Vorabversionen von Android 12 ab 2020 boten keinen 32-bit Emulator für Entwickler mehr an. Android 12 wurde im Oktober 2021 veröffentlicht, der Marktanteil von Android-Versionen bis Version 4 war bis April 2021 auf unter 2 % gefallen.

Außer für Embedded-Plattformen mit ihren spezialisierten Programmen, schwindet die Beachtung des Large File Support im Programmcode damit ab 2020.

Verwandte Probleme

Insbesondere das Jahr-2038-Problem zeigt auf, dass die traditionelle Darstellung von Zeitstempeln als 32-Bit „long“ zu Problemen führen kann. Diese werden sich mit dem Übergang zu reinen 64-Bit Systemen ebenfalls überholen. Zwischenzeitlich wurde begonnen, auch auf 32-Bit Systemen einen 64-Bit Zeitstempel verfügbar zu machen. In der Win32 API führte das dazu, dass neue Funktionen mit 64-Bit Zeitstempel das Suffix „64“ bekamen, und entsprechend die 64-Bit Dateilängen durch ein angehängtes Suffix „i64“ markiert wurden – durchaus auch in allen vier Kombinationen (findfirst32, findfirst64, findfirst32i64, findfirst64i32). Die UNIX98 API dagegen führt mit „_LARGEFILE64_SOURCE“ zusätzliche Funktionen mit dem Suffix „64“ ein.

Mit der large-file API verwandt sind Blockzähler für Massenspeicher, die durch eine übliche Größe der Datenblöcke von 512 Bytes erst später an die Begrenzung der 32-Bit Zahlen führte. Als Festplatten die Größe von 2 Terabyte erreichten (um 2010) musste daher der Master Boot Record als Partitionstabelle durch die GUID Partition Table ersetzt werden, der für die LBA (linear block address) dann 64-Bit Zähler definierte. Die in unixoiden System verwendeten inode-Zähler mussten ebenfalls aufgeweitet werden, ebenso wie andere Dateizähler (beispielsweise mit den Funktionen stat64 / setrlimit64). Die Überarbeitung des Linux Kernels erfolgte um 2001 zur Version 2.4, zusammen mit der Einführung der LFS Unterstützung, die dann von der glibc übernommen wurde. Da die Umstellung zeitgleich erfolgte, werden bei der GNU-C-Bibliothek für Linux mit der Aktivierung von 64-Bit LFS in 32-Bit-Architekturen auch die inode-Blockzähler und verwandte Funktionen auf 64-Bit umgestellt.

Das Dateisystem ext3 von 2001 übernahm dann im Treiber einige 64-Bit Werte, blieb aber auf dem Massenspeicher weiter auf 32-Bit Blockzähler begrenzt. Da man hier meist im Advanced Format von 4 Kilobyte Blöcken arbeitet, liegt das Maximum hier typisch bei 8 oder 16 Terabyte. Größere Massenspeicher im Bereich dutzender Terabyte mussten dann mit XFS formatiert werden, die 64-Bit inodes auch im Datenformat unterstützen, und somit bis in den Exabyte-Bereich vordringen. Die ersten 16 Terabyte Festplatten wurden ab Mitte 2019 ausgeliefert. Als Solid-State-Drive gab es Massenspeicher mit 32 TiB schon ab 2016, und für 2020 wurden diese jenseits 100 TiB angekündigt.

Siehe auch

• RF64 als 64-bit Erweiterung von RIFF WAVE Audiodateien
• FAT32+ als rückwärtskompatible Erweiterung des FAT Dateisystems (bis 256 GiB)
• ext4 als 48-bit Erweiterung des ext3 Dateisystems (>16 TiB ab e2fsprogs Version 1.42)

Weblinks

• Adding Support for Arbitrary File Sizes to the Single UNIX Specification