VOS-Streamdateien sind in ihrem Wachstum auf etwa 2 GB begrenzt. Das liegt daran, dass die Definition von Schnittstellen wie s$seq_position, s$get_port_status, s$lock_region usw. vorzeichenbehaftete 32-Bit-Variablen verwenden, um die Position in der Datei anzugeben, und 2**31 ist der größtmögliche Wert, der dargestellt werden kann. In Stream-Dateien ist die Position der Byte-Offset und nicht die Satznummer wie in anderen VOS-Dateiorganisationen.
64-Bit-Streamdateien sind ab Release 17.2 verfügbar und ermöglichen ein Wachstum, das nur durch das VOS-Dateisystem begrenzt ist (die maximale Größe einer Datei beträgt 512 GB). Neben der Erweiterung des Wachstumspotenzials bieten diese Dateien weitere Vorteile, insbesondere beim Zugriff auf Binärdaten. Anders als bei normalen Stream-Dateien belegen Blöcke, die ausschließlich binäre Nullen enthalten, keinen Platz auf der Festplatte, und das Lesen solcher Daten erfordert keinen Plattenzugriff.
Posix-konforme Anwendungen können leicht für große Dateien erstellt werden, ohne dass der Quellcode geändert werden muss: neue Dateien, die auf Festplatten mit 17.2+ Modulen erstellt werden, sind 64-Bit-Dateien (oft als stream64 bezeichnet) und auf Modulen vor 17.2 sind es gewöhnliche stream-Dateien. Anwendungen, die die VOS s$-Schnittstelle oder VOS Language I/O verwenden, werden als native Anwendungen bezeichnet, und solche, die Stream-Dateien verwenden, können auf stream64-Dateien zugreifen, solange sie entweder keine Byte-Positionierungsoperationen verwenden (die Positionierung nach BOF oder EOF wird nicht als Byte-Positionierung betrachtet) ODER wenn die Datei jedoch ist, müssen sie modifiziert werden, um stream64-Dateien zu erstellen.
Hier finden Sie einige Informationen, die nützlich sein können, wenn Sie 64-Bit-Streamdateien verwenden möchten. Sie sind wie folgt gegliedert:
Bestehende Anwendungen und Kompatibilität
- Vorhandene Posix-Anwendungen
- Vorhandene native Anwendungen
- Kompatibilität
- Open-Source-Produkte
Sparsame Zuweisung
Dateikonvertierung
Physikalische Merkmale
- Ausmaße
- Wie sich Extents auf die Sparse Allocation auswirken
- Flexible Erstreckungen
Werkzeuge
- Auffinden von 64-Bit-Stream-Dateien auf einem Modul
- Block-Vergleiche
- Vergleich von Sparse-Dateien
Bestehende Anwendungen und Kompatibilität
- Vorhandene Posix-Anwendungen
Ab Release 17.2 können Posix-Anwendungen für große Dateien erstellt werden, so dass sie auf 64-Bit-Dateien zugreifen und diese erstellen können, wenn sich das Ziel auf einer Festplatte befindet, die auf 17.2 oder höher läuft. Wenn die Anwendung Posix-konform ist (z.B. so kodiert ist, dass Typen wie off_t anstelle von int verwendet werden, wo dies erforderlich ist), dann sind keine Quelltextänderungen erforderlich; erstellen Sie sie einfach wie im OpenVOS POSIX.1 Referenzhandbuch, R502, "Portierung bestehender Anwendungen auf die 64-Bit Stream File Umgebung" beschrieben. Wenn eine Datei, die erstellt wird, auf einer Festplatte auf einem Modul vor 17.2 läuft, dann wird eine normale Stream-Datei erstellt, und alles wird in Ordnung sein, wobei ein Fehler nur dann auftritt, wenn ein Versuch unternommen wird, die Datei über 2 GB zu vergrößern. Wenn Sie also Ihre Posix-Anwendung in die Lage versetzen, große Dateien zu verwenden, kostet das in Bezug auf die Interoperabilität nichts. Die meisten von VOS unterstützten Open-Source-Produkte können ab Release 17.2 64-Bit-Streamdateien erzeugen und korrekt verarbeiten.
Posix-konforme Anwendungen können leicht für große Dateien erstellt werden, ohne dass der Quellcode geändert werden muss: Neue Dateien, die auf Festplatten mit 17.2+ Modulen erstellt werden, sind 64-Bit-Stream-Dateien (oft als stream64 bezeichnet) und auf Modulen vor 17.2 sind es normale Stream-Dateien. Anwendungen, die die VOS s$-Schnittstelle oder VOS Language I/O verwenden, werden als native Anwendungen bezeichnet, und solche, die Stream-Dateien verwenden, können auf stream64-Dateien zugreifen, solange sie entweder keine Byte-Positionierungsoperationen verwenden (Positionierung nach BOF oder EOF gilt nicht als Byte-Positionierung) ODER wenn die Datei kleiner als 2 GB ist.
- Vorhandene einheimische Anwendungen
Viele native Anwendungen müssen einfach die Verwendung des create_file-Befehls (oder s$create_file) ändern, um anzugeben, dass die Organisation STREAM64 und nicht STREAM ist. Wenn die Anwendung Positionierungsoperationen verwendet und die Datei auf > 2 GB anwächst, dann wird s$seq_position einen Fehler produzieren: um größere Dateien zu unterstützen, müssen s$seq_position-Aufrufe in s$seq_position_x geändert werden. Auch hier gilt, dass die Verwendung von _x-Schnittstellen nicht die Fähigkeit der Anwendung beeinträchtigt, auf normale Stream-Dateien zu verweisen, die auf Modulen existieren, die die _x-Schnittstellen nicht unterstützen, solange die Positionsargumente im unterstützten Bereich liegen. Die Änderung ermöglicht also den Zugriff auf jeden Typ von Streamdateien und hat keine Auswirkungen auf die Interoperabilität.
Bestehende Anwendungen, die nur Schnittstellen verwenden, die keine Byte-Position kommunizieren: s$seq_read, s$seq_write, s$seq_position BOF/EOF, können ohne Änderung mit stream64-Dateien umgehen. Viele Anwendungen sind für den Umgang mit ASCII-Dateien geschrieben, unabhängig davon, ob es sich um sequentielle oder Stream-Dateien handelt, und benötigen daher keine Änderung, um mit 64-Bit-Stream-Dateien umgehen zu können, unabhängig von ihrer Größe.
64-Bit-Streamdateien können keine Indizes haben, und daher kann eine indizierte Streamdatei nicht in stream64 konvertiert werden. Indizierte Stream-Dateien können aufgrund von Einschränkungen in der bestehenden Index-Implementierung nicht auf > 2 GB anwachsen.
- Kompatibilität
Da 64-Bit-Streamdateien eine Reihe von Vorteilen bieten, sollten sie nach Möglichkeit verwendet werden, wenn ein Index nicht erforderlich ist.
Solange die Datei nicht größer als 2 GB wird, kann sie auf Module mit älteren VOS-Versionen kopiert oder verschoben werden und erscheint dort als normale Stream-Datei. Sie können sogar einen Datenträger mit stream64-Dateien in ein älteres VOS verschieben, sofern die Dateien nicht "eingeschränkt" sind. Eine Datei ist eingeschränkt, wenn sie größer als 2 GB ist oder nur spärlich belegt ist; solche Dateien können nicht geöffnet werden, wenn der Datenträger, auf dem sie sich befinden, auf ein VOS vor 17.2 verschoben wird (es gibt Tools, um eingeschränkte Dateien zu identifizieren, wenn Sie einen solchen Umzug planen). Anwendungen, die unter älteren VOS-Versionen laufen, können jedoch jede Art von stream64-Dateien über das Netzwerk öffnen, lesen und schreiben; jeder auftretende Fehler ist derselbe, als ob die Anwendung unter 17.2+ laufen würde (z. B. die Verwendung von s$seq_position für die Byte-Positionierung, wenn die Datei 2 GB überschreitet).
- Open-Source-Produkte
Die meiste unter VOS unterstützte Open Software wurde so konvertiert, dass sie für große Dateien geeignet ist, z.B. ftp, sftp, samba, etc. Das hat bestimmte Auswirkungen. Ab Version 17.2 können Sie nun eine Stream-Datei per ftp auf VOS übertragen und müssen sich keine Sorgen mehr machen, dass die Datei zu groß ist, da der ftp-Daemon eine stream64-Datei erstellt. ftp schreibt alle Bytes, so dass die resultierende Datei nicht spärlich ist (siehe nächster Abschnitt), auch wenn sie hauptsächlich aus binären Nullen besteht. Das einfache Kopieren der übertragenen Datei kann den Speicherplatz, den sie belegt, erheblich reduzieren. Wenn Sie der per ftp übertragenen Datei einen Index hinzufügen wollen, müssen Sie sie zunächst in eine normale Stream-Datei umwandeln (und natürlich darf sie nicht länger als 2 GB sein).
Spärliche Zuweisung
Blöcke, die ausschließlich binäre Nullen enthalten, werden für stream64-Dateien nicht immer zugewiesen und benötigen daher keinen Speicherplatz. Der gnu-Befehl "truncate" (in >system>gnu_library>bin) kann sowohl zum Abschneiden als auch zum Erweitern der Größe einer stream-Datei verwendet werden. In 18.0 bietet VOS einen ähnlichen Befehl namens reset_eof. Daten nach EOF sind undefiniert, aber wenn EOF erweitert wird, wird der Dateiinhalt ab dem Punkt des aktuellen EOF immer auf binäre Nullen gesetzt.
Betrachten Sie eine gewöhnliche Stream-Datei und eine stream64-Datei:
create_file stm -Organisation stream
create_file s64 -Organisation stream64
und nehmen an, dass jede den Inhalt "abc" hat. Wir möchten die Dateien so erweitern, dass jede 2 Milliarden Bytes belegt:
bash
bash-4.2$ truncate -s 2000000000 s64
bash-4.2$ trunkieren -s 2000000000 stm
Die erste Anfrage wird sofort beendet, während die zweite mehrere Minuten dauert. Die Dateien sind logisch äquivalent:
bash-4.2$ ls -l
gesamt 244382
-rwxrwxrwx 1 nobody nobody 2000000000 Feb 25 14:08 s64
-rwxrwxrwx 1 nobody nobody 2000000000 Feb 25 14:11 stm
Die Anzahl der Plattenblöcke, die jede Datei belegt, ist jedoch sehr unterschiedlich, wie der VOS-Befehl list zeigt:
Liste
Dateien: 2, Blöcke: 488764
w 4 s64
w 488760 stm
In Release 18.0 können die entsprechenden Operationen mit dem VOS-Befehl reset_eof durchgeführt werden:
reset_eof s64 2000000000
Der VOS-Befehl gibt eine Warnung aus, wenn Sie eine gewöhnliche Stream-Datei um mehr als ein paar tausend Blöcke erweitern wollen, da dies eine sehr kostspielige Operation ist
reset_eof stm 2000000000
Wenn Sie eof auf 2000000000 erweitern, werden der Datei 488281 Blöcke hinzugefügt. Möchten Sie stm um 1999999996 Bytes erweitern? (ja, nein)
Hier ist die 64-Bit-Stream-Datei nach der Erweiterung. Sie besteht aus nur zwei Datenblöcken:
dump_file s64
Blocknummer 1
000 6162630A 00000000 00000000 00000000 |abc.............|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Blocknummer 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Ein Dumping der normalen Stream-Datei stm zeigt alle 488282 Blöcke, die zugewiesen wurden, wobei die meisten Blöcke binäre Nullen enthalten.
dump_file stm
Blocknummer 1
000 6162630A 00000000 00000000 00000000 |abc.............|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Block Nummer 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Block Nummer 3
…
Blocknummer 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
Dennoch sehen compare_files und diff die Dateien als gleichwertig an, müssen aber alle Blöcke in der gewöhnlichen Stream-Datei durchlesen, was in diesem Fall einige Minuten dauern kann:
bereit;vergleiche_dateien s64 stm
bereit 14:29:47
bereit 14:31:24 45.877 46
Dateikonvertierung
Der Befehl convert_stream_file steht zur Verfügung, um zwischen den Dateitypen sequentiell und stream (stream, 64-bit stream, sequentiell und erweitert sequentiell) zu konvertieren und den Umfang zu ändern. In der Regel wird bei der Konvertierung der Inhalt der Datei kopiert, was der Erstellung einer leeren Zieldatei und der Verwendung von copy_file mit der Option -truncate ähnelt. convert_stream_file kann verwendet werden, um die Datei an Ort und Stelle zu ändern, und hat den Vorteil, dass vor der Konvertierung sichergestellt wird, dass der vorhandene Inhalt im gewünschten neuen Format dargestellt werden kann.
There are cases where a stream file can be reset to stream64 and vice versa without conversion, i.e., without copying contents. This is done by resetting the directory entry and is possible only if the file is not sparse, is less that 2 GB and extent size is not changed. This can be useful when migrating a disk containing stream64 files to a pre-17.2 module and again if the disk is moved back. The set_stream_files command is available for this purpose. It is a privileged command intended for use by a System Administrator: it takes a directory as input and resets files in that directory, and optionally in all sub-directories. It affects only those stream64 files which can be reset without conversion (not sparse and otto>stm
file organization: stream file
last used at: 15-02-25 14:34:45 est
…
extent size: 1
next byte: 2000000000
blocks used: 488760 <<<<<
Dann:
convert_stream_file stm -to stream64 -extent_size 8
display_file_status stm
file organization: stream file (64-bit/rstr)
last used at: 15-02-25 14:39:16 est
…
extent size: 8
next byte: 2000000000
blocks used: 18 <<<<
sparse: yes
Die resultierende Datei wird als eingeschränkt (64-bit/rstr) angezeigt, da sie nun spärlich ist. Der Befehl copy_file erzeugt ebenfalls eine Sparse-Datei. Die Konvertierung einer stream64-Datei in eine gewöhnliche Stream-Datei führt dazu, dass alle Blöcke instanziiert werden, so dass die resultierende Datei erheblich größer sein kann als das Original.
In einer stream64-Datei gibt es keine Garantie dafür, dass ein Block, der zufällig binäre Nullen enthält, auf der Festplatte zugewiesen wird oder nicht. Wenn Sie z.B. einige Nullen in einen Block schreiben, der am Ende nur aus Nullen besteht, bleibt der Block zugewiesen - oder wenn ein Programm explizit Null-Daten schreibt, die Blöcke auffüllen. Nur Blöcke, die nie geschrieben werden, bleiben unallokiert; copy_file und convert_stream_file schreiben nie Blöcke, die nur binäre Nullen enthalten.
Physikalische Merkmale
- Ausmaße
Die tatsächliche Wachstumsgrenze einer VOS-Datei wird durch ihre Extent-Größe bestimmt, daher ist es wichtig zu verstehen, was ein Extent ist. Die VOS-Dateimap enthält Festplattenadressen für jeden 4k-Block in einer Datei; sie ist auf 523792 Einträge begrenzt, so daß jede Datei ohne Extents auf 2145452032 (523792 * 4096) Bytes begrenzt ist. Dies ist etwas weniger als 2**31 und stellt somit die tatsächliche Grenze für das Wachstum einer gewöhnlichen Stream-Datei dar.
Ein Extent ist eine Gruppe von N zusammenhängenden Blöcken auf der Festplatte, wobei N die Größe des Extents ist. Die Dateizuordnung für eine über Extents zugewiesene Datei enthält die Adresse des ersten Blocks im Extent und ermöglicht es der Dateizuordnung somit, eine wesentlich größere Datei darzustellen. Dynamisch zugewiesene Extents erlauben eine Extent-Größe von bis zu 256, was eine Datei mit 512 GB ermöglicht (Hinweis: Statisch zugewiesene Extents, die eine Extent-Größe von mehr als 256 erlauben, sind veraltet, außer für die Verwendung mit Auslagerungsdateien; diese haben viele Einschränkungen und Leistungsprobleme, die sie für den allgemeinen Gebrauch inakzeptabel machen).
Um über 2 GB hinaus wachsen zu können, muss eine stream64-Datei über Extents verfügen, deren Wert die tatsächliche Wachstumsgrenze bestimmt. Zum Beispiel,
create_file stm64 -organization steam64 -extent_size 32
wird eine Datei erstellt, die bis zu 64 GB groß werden kann.
In Version 17.2 beträgt die Standardgröße für Dateien, die von Posix Runtime erstellt werden, 8 Blöcke, was ein Wachstum bis zu 16 GB ermöglicht. Solche Dateien wachsen jeweils um 8 Blöcke, so dass die Mindestgröße einer Datei 8 Blöcke beträgt. Dieser Standardwert kann von einem Systemadministrator für jedes Modul geändert werden, aber je größer das Wachstumspotenzial, desto größer die Mindestgröße einer Datei. Größere Extents können ein Problem für Anwendungen darstellen, die viele sehr kleine Dateien erzeugen.
- Wie sich Ausmaße auf die Sparse-Zuweisung auswirken
Normalerweise werden Blöcke, die nie geschrieben werden, für stream64-Dateien nicht zugewiesen; wenn jedoch ein Block in einem Extent geschrieben wird, werden alle Blöcke in diesem Extent zugewiesen, auch wenn einige nur binäre Nullen enthalten.
Angenommen, eine Nicht-Extent-Datei, die die Zeichenfolge abc (stm1) enthält, wird in eine Datei mit der Extent-Größe 8 (stm8) konvertiert:
dump_file stm1
Block Nummer 1
000 6162630A 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
Block Nummer 1
000 6162630A 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Block Nummer 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Block Nummer 3
…
Blocknummer 8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Die Option -brief wurde in Version 18.0 zu dump_file hinzugefügt und kann nützlich sein, wenn Sie Blöcke nicht sehen wollen, die physisch vorhanden sind, sondern "leere" (möglicherweise nicht existierende) Blöcke darstellen. Die Verwendung dieser Option mit der DAE-8-Datei wird unten gezeigt:
dump_file stm8 -brief
Block Nummer 1
000 6162630A 00000000 00000000 00000000 |abc.............|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000 |................|
Auf diese Weise lassen sich auch "leere" Blöcke, die alle -1′s enthalten, relativ zu den festen Dateien ausblenden.
- Flexible Ausmaße
In Release 18.0 wurden flexible Extents eingeführt, die es einer kleinen Datei erlauben, blockweise zu wachsen; wenn die Datei größer wird, ändert sich der Extent-Wert. Dies ist die Standardeinstellung für alle Dateien, die von Posix-Anwendungen in Release 18.0 erstellt werden, und ist das, was Sie mit dem Befehl create_file erhalten, wenn Sie keine bestimmte Extent-Größe angeben:
create_file flex -organization stream64 -extent_size
Dateien mit flexiblen Extents werden als Flex-Dateien bezeichnet; nur stream64-Dateien können flexible Extents haben. Der Befehl display_file_status zeigt die Extentgröße einer Flex-Datei als "flex" an.
display_file_status flex
Name: %swsle#Raid4>flex
Dateiorganisation: Stromdatei (64-bit)
zuletzt geändert am: 15-02-25 12:06:25 est
…
dynamische Ausmaße: ja
Umfangsgröße: flexibel
Wenn der Befehl display_file_status auf einem Modul vor 18.0 ausgeführt wird, zeigt er an:
extent size: -1
Wenn eine Flex-Datei auf einen Datenträger mit einem 17.2-Modul kopiert wird, hat sie die für dieses Modul vorgegebenen Extents. Wird sie auf ein Modul 17.1 oder früher kopiert, ist das Ergebnis eine gewöhnliche Stream-Datei.
In Version 17.2+ erkennt compare_files keine Größenunterschiede zwischen Streamdateien, und die Dateien erscheinen unabhängig von der Größe des Umfangs identisch. Nehmen wir zum Beispiel an, dass %swsle#m109_mas auf einem Modul unter 17.2 läuft:
copy_file flex %swsle#m109_mas>Stratus
vergleiche_dateien flex %swsle#m109_mas>Stratus>flex
bereit 14:42:38 0.001 6
Wenn Sie compare_files mit einem Modul vor Version 17.2 ausführen, wird dies als Unterschied angezeigt:
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex stimmt nicht mit B (%swsle#m109_mas>Stratus>flex) überein.
- Einige Attribute der beiden Dateien stimmen nicht überein:
extent size -1 8
Flex-Dateien können etwas weniger als 512 GB fassen, nämlich 540.142.534.656 Bytes gegenüber 549.235.720.192 mit DAE-256, haben aber den Vorteil, dass kleine Dateien blockweise wachsen, erst 8, dann 32, dann 256 und nicht immer 256 Blöcke auf einmal.
Sie sollten einen Datenträger mit Flex-Dateien nicht in ein Modul vor 18.0 einbinden; es gibt Werkzeuge, mit denen Sie einen Datenträger leicht auf das Vorhandensein von Flex-Dateien untersuchen können. Wenn Sie dies versehentlich tun, sind die Dateien nicht sichtbar und es kann nicht darauf zugegriffen werden. Solche Dateien oder die Verzeichnisse, die sie enthalten, können nicht gelöscht werden und bleiben daher intakt, wenn der Datenträger wieder auf ein Modul mit 18.0+ verschoben wird. Wenn Sie jedoch auf ein Modul vor 18.0 retten, werden alle Flex-Dateien gelöscht und der Speicherplatz wird wiederhergestellt.
Werkzeuge
- Auffinden von 64-Bit-Stream-Dateien auf einem Modul
Wenn Sie einen Datenträger in eine ältere Version von VOS verschieben wollen, müssen Sie die Dateien finden, die mit der älteren Version nicht kompatibel sind. Dazu gibt es einen Befehl, der Sie dabei unterstützt:
locate_stream_files -form
---------- locate_stream_files ---------
directory_names:
-depth:
-type: 64-bit
-brief: nein
-long: nein
-type kann auch flex, sparse oder large sein (dann werden 64-Bit-Streamdateien mit dieser spezifischen Eigenschaft gefunden) oder all (dann werden alle Streamdateien gefunden).
Abhängig von -depth werden untergeordnete Verzeichnisse durchsucht, und wenn die Datei eines der Attribute (nicht durch den Typ spezifiziert) hat, werden auch Informationen dazu und die Extentgröße angezeigt. Wenn kein Verzeichnisname angegeben wird, werden alle Festplatten des Moduls vom Stammverzeichnis aus durchsucht. Zum Beispiel:
locate_stream_files -type 64-bit
Überprüfen der Verzeichnisse auf der Platte %swsle#raid0-1...
%swsle#raid0-1:
smb_test.stm64 (FLEX/groß)
smb_test.stmb
Insgesamt 2 64-Bit-Stream-Dateien.
Überprüfen der Verzeichnisse auf der Platte %swsle#raid0-2...
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/groß)
Insgesamt 3 64-Bit-Stream-Dateien.
Überprüfung der Verzeichnisse auf der Festplatte %swsle#Raid4...
%swsle#Raid4>otto:
b3 (DAE-8)
groß (DAE-256/groß/sparsam)
…
- Block vergleicht
In den Versionen 17.2 und 18.0 sind neue Optionen für den Befehl compare_files verfügbar, die für Streamdateien nützlich sind. Ein blockweiser Vergleich von strukturierten VOS-Dateitypen ist in der Regel nicht sinnvoll, da zwei Blöcke mit unterschiedlichen Werten oft dieselben logischen Datensätze darstellen. Zum Beispiel sind ungenutzte Daten in den Sätzen einer relativen Datei nach ihrer aktuellen Länge unvorhersehbar. Darüber hinaus enthalten sequentielle Dateien undefinierte Füllbytes. Die Blockinhalte von erweiterten sequentiellen Dateien sind völlig unterschiedlich, wenn die Satzgröße unterschiedlich ist, obwohl sie dieselben logischen Sätze repräsentieren.
Blockvergleiche können jedoch manchmal für feste und Stream-Dateien nützlich sein. Das Problem ist, dass compare_files satzorientiert ist und Unterschiede in Form von Satznummern (oder Zeilennummern) anzeigen soll, die mit einem Editor gefunden werden können. Bei binären Stream-Dateien, die nicht in Form von Sätzen organisiert sind, hat dies zu Problemen geführt. Da die Datensatzgröße für jede Datei auf 32767 Bytes begrenzt ist, liefert die Verwendung von s$seq_read in einer Stream-Datei bei einer Sequenz von mehr als 32k Bytes ohne einen dazwischenliegenden NL-Datensatzbegrenzer die nächsten 32767 Zeichen und unterscheidet nicht, ob das nächste Byte ein NL war oder nicht. Dies macht das Ergebnis des datensatzorientierten Vergleichs für Streamdateien, die Binärwerte und keine durch das NL-Zeichen getrennte Zeichenfolge enthalten, mehrdeutig.
Dieses Problem wurde in Version 17.2 behoben; compare_files erkennt Fälle, in denen zuvor ein falscher Erfolg auftrat - insbesondere wenn 32767 Zeichen gefolgt von einem NL mit 32767 Zeichen übereinstimmen, die nicht von einem NL gefolgt werden. Wenn dies der Fall ist, wird ein Fehler gemeldet, der darauf hinweist, dass die Stream-Datei Datensätze > 32767 enthält. Tritt dieser Fall nie ein, sind die datensatzorientierten Ergebnisse gültig und können als zuverlässig angesehen werden. Wenn Sie jedoch nur sicherstellen wollen, dass die Dateien identisch sind, ist der Vergleich der Blöcke einer unstrukturierten Datei in jedem Fall viel schneller als die datensatzorientierte Methode. Das Problem bei Blockvergleichen ist, dass ohne Datensätze, die als Wegweiser dienen, der Vergleich nach der ersten Abweichung oft sinnlos ist.
In Version 17.2 wurde zu diesem Zweck die Option -compare_blocks zum Befehl compare_files hinzugefügt. Damit lässt sich schnell feststellen, ob unstrukturierte Dateien Block für Block identisch sind, und der Block, an dem sie sich unterscheiden, wird ermittelt. Für den seltenen Fall, dass der Unterschied auf eine Überlagerung zurückzuführen ist (bestimmte Bytes wurden geändert und nicht eingefügt oder gelöscht) und der Rest der Dateien identisch ist, gibt es auch die Option -continue. Damit wird der Bereich der Blöcke in der restlichen Datei angezeigt, die sich unterscheiden. Wenn zum Beispiel ein Byte eingefügt wurde (im Gegensatz zu einer Überlagerung), dann unterscheiden sich alle verbleibenden Blöcke; das heißt, eine Neusynchronisierung, wie sie bei Datensatzvergleichen durchgeführt wird, ist bei Blockvergleichen nicht möglich. In dem erwähnten Fall könnte diese zusätzliche Information jedoch sicherstellen, dass der einzige Unterschied in einigen wenigen Blöcken einige überlagerte Bytes waren, die vielleicht so etwas wie einen Zeitstempel darstellen.
Als Beispiel für -compare_blocks mit -continue:
compare_files flex dae256 -compare_blocks -continue
A (%swsle#m111_mas>Stratus>Newman>flex) stimmt nicht mit B (%swsle#m111_mas>Stratus>Newman>dae256) überein.
- Die Datenblöcke von 2 bis 24 unterscheiden sich.
- Datenblöcke von 33 bis 488 unterscheiden sich.
- 272 zusätzliche Blöcke in Datei B.
- Vergleich von spärlichen Dateien
Der Befehl compare_files betrachtet alle physisch vorhandenen Blöcke in einer Datei. Dies kann bei spärlichen Dateien ein Problem darstellen, da ein Block mit binären Nullen in einer Datei als zugewiesener Block erscheinen kann, in einer anderen jedoch nicht vorhanden ist. Die Dateien können logisch identisch sein, aber nicht Block für Block. Durch die Verwendung von copy_file werden Blöcke mit binären Nullen in der Zieldatei eliminiert, und falls welche vorhanden sind, garantiert dies, dass die Quelle und das Ziel nicht Block für Block identisch sind.
Dies ist auch ein Problem in extentbasierten Streamdateien, da alle Blöcke in einem extent immer instanziiert werden, auch wenn sie nur binäre Nullen enthalten. Das bedeutet, dass die Blöcke in einer Sparse-Extent-Datei anders aussehen können als die Blöcke in einer identischen Nicht-Extent-Datei, auch wenn sie genau dieselben Daten repräsentieren. Die Ausführung von copy_file kann Nullblöcke in einem Extent nicht eliminieren.
Das obige Beispiel, das die Verwendung von -continue zeigt, betrifft eigentlich zwei identische Dateien, außer dass die eine DAE-256-Extents und die andere flexible Extents hat.
Eine DAE-8-Datei mit dem Inhalt "abc" enthält also einen Block mit "abc", gefolgt von 7 weiteren Blöcken mit binären Nullen. Eine Nicht-Extent-Datei (oder Flex-Datei) enthält nur einen Block mit "abc", und eine DAE-16-Datei enthält einen "abc"-Block, gefolgt von 15 Blöcken mit binären Nullen.
Wenn Sie den Befehl compare_files mit -compare_blocks verwenden, werden alle diese Dateien als unterschiedlich angezeigt, obwohl sie alle dieselben Dateidaten darstellen. In Release 18.0 ist für diese Situation die Option -compare_all_blocks verfügbar. Sie veranlasst copy_file, fehlende Blöcke in den zu vergleichenden Dateien logisch zu instanziieren, so dass ein echter Block-für-Block-Vergleich durchgeführt wird, bei dem die durch Sparsamkeit verursachten Unterschiede eliminiert werden. Fehlende Blöcke in stream64-Dateien werden als binäre Nullen betrachtet, während sie in fixed (oder allen anderen Dateitypen) als binäre -1′s (alle FFFF) betrachtet werden.
In einer sehr spärlichen Datei kann dies den Vergleich viel langsamer machen als die Verwendung der Optionen -compare_blocks, aber immer noch deutlich schneller als der standardmäßige datensatzorientierte Vergleich. Diese Option wird in der Regel nur benötigt, wenn Blöcke von Dateien mit unterschiedlichem Umfang verglichen werden, obwohl es wie erwähnt auch andere Fälle gibt, in denen die Spärlichkeit unterschiedlich sein kann. Dies ist auch für feste Dateien mit unterschiedlichen Extents nützlich.