lfs(5) lfs(5)
NAME
lfs - Large File Summit
BESCHREIBUNG
Das Problem mit großen Dateien (> 2 GB)
Die 32-Bit-orientierten UNIX Systeme unterstützen Dateigrößen von
maximal 2^31-1 Bytes. Diese Beschränkung ist durch die Definition des
Datentyps "off_t" als "signed 32-Bit-long" vorgegeben. Dies reicht
für heutige Anwendungen, in denen Video-, Audio- und Abbilddateien
sowie große Datenbanken enthalten sind, nicht mehr aus. Die heutigen
32-Bit-Systeme können zwar den rechenbezogenen Prozeß dieser Anwendun-
gen problemlos handhaben, müssen jedoch auch maximale Dateigrößen
unterstützen, die um ein Vielfaches über den herkömmlichen Dateigrößen
liegen ("Large File Support", LFS).
Das Problem kann durch eine komplette Portierung von 32 auf 64 Bit
gelöst werden. Dabei wird z. B. die Datentypdefinition für "off_t"
geändert in ein "signed 64-Bit-long".
Eine solche Portierung würde sowohl den Kern als auch alle Anwendungen
betreffen, was mit einem sehr hohen Aufwand verbunden wäre. Ein 32-Bit
UNIX System, das gezielt Dateien > 2 GB unstützt, bzw. ein 64-Bit UNIX
System, das "per Definition" in der Lage ist, sehr große Dateien zu
handhaben, muß berücksichtigen:
- daß existierende 32-Bit-Binärprogramme nicht mehr geändert werden
können,
- daß vorhandene Anwendungssoftware gegebenenfalls schrittweise von
32 auf 64 Bit umgestellt wird (Portierung als 64-Bit-Programm) und
- daß vorhandene Anwendungssoftware aus Aufwandsgründen nur bezüglich
der Dateiverarbeitung auf 64 Bit portiert wird (die Anwendung
bleibt weiterhin ein 32-Bit-Programm und nutzt lediglich die LFS-
Schnittstellen).
Außerdem muß die Interoperabilität zwischen 32-/64-Bit-Systemen
gewährleistet werden.
Führende Systemlieferanten und Softwarehersteller haben sich im Rahmen
des "Large File Summit" getroffen, um eine Reihe von Änderungen zur
bestehenden Single UNIX Specification (SUS) zu erarbeiten, über die
sowohl neue als auch alte Programme Dateien "beliebiger" Größe adres-
sieren können. Diese Änderungen werden in die nächste SUS von X/Open
eingearbeitet. Weitergehende Informationen zum "Large File Summit" und
zur LFS-Spezifikation sind unter http://www.sas.com/standards/large.file
zu finden.
Seite 1 Reliant UNIX 5.44 Gedruckt 11/98
lfs(5) lfs(5)
Anforderungen
Folgende Anforderungen wurden in der LFS-Spezifikation berücksichtigt:
- Schutz bestehender Programme (bezüglich Überlauf bei Daten, die als
offt definiert sind, z. B. stsize in struct stat)
- Schutz großer Dateien vor Programmen, die nur Dateien bis 2 GB ver-
arbeiten können (und durch Fehlreaktion den Datenbestand einer gro-
ßen Datei gefährden würden)
- Zugriff auf Dateien mit einer Größe von weit mehr als 2 GB auf 32-
Bit-Betriebssystemen bzw. von 32-Bit-Anwendungen auf 64-Bit-Be-
triebssystemen
- Vollständige Einhaltung der SUS
- Erweiterung zur SUS
Konzepte
Die konsistente Umsetzung einiger weniger technischer Grundkonzepte
diente als "Leitfaden" für die Erarbeitung der LFS-Spezifikation:
Verschiedene Größen von offt
Während einer Übergangszeit von reinen 32-Bit- zu reinen 64-Bit-
Systemen und -Anwendungen ist es notwendig, daß 2 Größen von
offt (und davon abgeleiteten Datentypen) unterstützt werden:
- in Systemen mit einer gemischten offt-Umgebung (offt kann in
einem Binärprogramm 32- oder 64-Bit-long sein),
- in Systemen mit einer wählbaren offt-Umgebung (offt ist in
einem Binärprogramm entweder 32- oder 64-Bit-long),
- in Netzwerken können Client/Server verschiedene offt-Defini-
tionen haben.
Offset-Maximum
Die meisten, leider jedoch nicht alle numerischen Daten in der
SUS sind als "nicht transparente" (opaque) Datentypen definiert
(d. h. die SUS verwendet in der Regel nicht die Basisdatentypen
der C-Sprache; eine Ausnahme ist z. B. ulimit(2): deshalb wird
der ulimit-Systemaufruf nicht in der LFS-Spezifikation berück-
sichtigt). Diese abgeleiteten Datentypen können anstelle der
Basisdatentypen der C-Sprache eingesetzt werden, um eine porta-
ble, source-kompatible Schnittstelle zum Betriebssystem zu reali-
sieren und so z. B. die bereits erwähnten Überlaufprobleme zu
vermeiden. Für die gebundenen Binärprogramme müssen die "nicht
transparenten" Datentypen jedoch auf Basistypen abgebildet werden
(z. B. auf ein 32-Bit-long). Dabei kann es bei Daten, die z. B.
für die Darstellung der Dateigröße oder der aktuellen Dateiposi-
tion bestimmt sind, zu einem Überlauf im Wertebereich kommen,
wenn die zu verarbeitende Datei größer als 2 GB ist.
Seite 2 Reliant UNIX 5.44 Gedruckt 11/98
lfs(5) lfs(5)
Zum Schutz dieser reinen 32-Bit-Binärprogramme als auch zum
Schutz des Datenbestands einer großen Datei wird das Konzept des
"Offset Maximum" realisiert: beim Eröffnen einer Datei [z. B.
durch open(2) oder creat(2)] teilt das Anwendungsprogramm (impli-
zit bei 64-Bit-Programmen oder explizit per Flag) mit, ob es in
der Lage ist, Dateien größer 2 GB zu verarbeiten. In diesem Fall
wird kern-intern in der mit dem Filedescriptor verknüpften Datei-
beschreibung das sog. "Offset Maximum" hinterlegt: das entspricht
dem Wert für die maximale Dateiposition, auf die in der Datei
positioniert werden kann.
Für 32-Bit-Programme, die beim open/creat nicht angeben, daß sie
eine große Datei verarbeiten können, wird ein "Offset Maximum"
von 2 GB-1 eingetragen.
Alle Operationen einer Anwendung,
- deren "Offset Maximum" nicht mit der aktuellen Dateigröße
übereinstimmt [open(2), creat(2) usw.]
- oder die aktuelle Dateigröße nicht korrekt darstellen können
[stat(2), fstat(2), fcntl(2) usw.]
- oder bei denen versucht wird, sich über das "Offset Maximum"
hinaus zu positionieren [explizit per lseek(2), implizit per
write(2)/read(2)],
werden mit Fehler abgebrochen.
EOVERFLOW
In der aktuellen SUS ist kein Fehler für den Fall definiert, daß
das "Offset Maximum" überschritten wird oder ein Datum nicht kor-
rekt dargestellt werden kann. EOVERFLOW ist ein bereits vorhande-
ner Fehlertyp, der in die Beschreibungen der relevanten System-
schnittstellen aufgenommen werden muß, damit die neue Fehlerbe-
dingung an die Anwendungen weitergegeben werden kann.
Entwicklungsmodelle
Neben den Schnittstellendefinitionen für die Verwendung unter-
schiedlicher Größen für offt sind in der LFS-Spezifikation auch
Entwicklungsmodelle berücksichtigt, mit denen der Quellcode von
existierenden Anwendungen übersetzt werden kann, die Dateien grö-
ßer 2 GB verarbeiten sollen.
Dazu ist es notwendig, die Größe von offt und allen zugeordneten
Datentypen anzugeben:
Seite 3 Reliant UNIX 5.44 Gedruckt 11/98
lfs(5) lfs(5)
Auswählbarer offt
In diesem Modell werden die bei der Kompilierung gültige
Größe von offt festgelegt sowie die entsprechenden Biblio-
theken, Include-Dateien und Datentypen während des Kompilie-
rungs- und Bindeprozesses ausgewählt. Alle beteiligten
Binärprogramme verwenden die gleiche Größe von offt, die
von der Entwicklungsumgebung als 32- oder 64-Bit-long
bereitgestellt wird (z. B. als Datentyp "long long", wenn
die Anwendung als 32-Bit-Programm mit LFS kompiliert wird).
Expliziter offt
In diesem Modell wird die Größe von offt während der Anwen-
dungsentwicklung angegeben (und damit im Quellcode festge-
schrieben). Die explizit angegebene Systemschnittstelle ver-
wendet einen offt einer vorgegebenen Länge.
In einer 32-Bit-Anwendung impliziert beispielsweise die Ver-
wendung von open() einen offt von 32 Bits, und die Verwen-
dung von open64() bzw. open(OLARGEFILE) impliziert einen
off64t von 64 Bits. (Dies gilt analog für die Verwendung
anderer expliziter 64-Bit-Versionen, z. B. lseek64(), vgl.
die Auflistung unter SIEHE AUCH.) Dieses Modell ist zwar
äußerst nützlich für die Unterstützung schrittweiser Konver-
tierungen, wird jedoch nicht direkt in der SUS unterstützt.
Es stellt lediglich eine Übergangserweiterung der SUS dar
(vgl. LFS-Spezifikation, Kap. 3).
HINWEISE
Dateien größer als 2 GB und Dateisysteme größer als 4 GB werden nur
für den Dateisystemtyp vxfs (Veritas) unterstützt.
SIEHE AUCH
creat64(2), fstat64(2), fstatvfs64(2), getrlimit64(2), lstat64(2),
mmap64(2), open64(2), setrlimit64(2), stat64(2), statvfs64(2),
fgetpos64(3C), fsetpos64(3C), ftruncate64(3C), ftw64(3C), lockf64(3C),
nftw64(3C), readdir64(3C), truncate64(3C), fopen64(3S), freopen64(3S),
fseeko64(3S), ftello64(3S), lseek64(3S), tmpfile64(3S).
Seite 4 Reliant UNIX 5.44 Gedruckt 11/98