I file VOS stream sono limitati in crescita a circa 2 GB. Questo perché la definizione di interfacce come s$seq_position, s$get_port_status, s$lock_region, ecc. utilizza variabili firmate a 32 bit per indicare la posizione nel file e 2**31 è il valore più grande possibile che può essere rappresentato. Nei file stream, la posizione è byte-offset piuttosto che numero di record come in altre organizzazioni di file VOS.
I file stream a 64 bit sono disponibili a partire dalla release 17.2 e consentono una crescita limitata solo dal file system VOS (la dimensione massima di qualsiasi file è di 512 GB). Oltre ad espandere il potenziale di crescita, questi file offrono altri vantaggi, in particolare per l'accesso ai dati binari. A differenza dei normali file di flusso, i blocchi contenenti tutti gli zeri binari non occupano spazio sul disco e la lettura di tali dati non richiede l'accesso al disco.
Le applicazioni conformi a Posix possono essere facilmente costruite per una grande consapevolezza dei file senza alcuna modifica dei sorgenti: i nuovi file creati su dischi che girano su moduli 17.2+ saranno file a 64 bit (spesso chiamati stream64) e su moduli pre-17.2 saranno file stream ordinari. Le applicazioni che usano l'interfaccia VOS s$ o VOS Language I/O sono chiamate applicazioni native e quelle che usano file stream saranno in grado di accedere ai file stream64 finchè o non usano operazioni di posizionamento a byte (il posizionamento su BOF o EOF non è considerato posizionamento a byte) O se il file è Tuttavia, dovranno essere modificate per creare file stream64.
Ecco alcune informazioni che possono essere utili se / quando si prevede di utilizzare i file di flusso a 64 bit. È organizzato come segue:
Applicazioni esistenti e compatibilità
- Applicazioni Posix esistenti
- Applicazioni native esistenti
- Compatibilità
- Prodotti Open Source
Assegnazione rada
Conversione dei file
Caratteristiche fisiche
- Estensioni
- Come le estensioni influiscono sulla scarsa allocazione
- Estensioni flessibili
Strumenti
- Individuare i file di flusso a 64 bit su un modulo
- Confronti a blocchi
- Confronto tra file sparsi
Applicazioni esistenti e compatibilità
- Applicazioni Posix esistenti
A partire dalla Release 17.2, le applicazioni Posix possono essere costruite per la consapevolezza di file di grandi dimensioni, permettendo quindi di accedere ai file a 64 bit e di crearli se il target è su un disco in esecuzione su 17.2 o oltre. Se l'applicazione è conforme a Posix (per esempio, è codificata per usare tipi come off_t invece di int dove richiesto), allora non sono necessarie modifiche alla sorgente; semplicemente la si costruisce come descritto nel manuale di riferimento di OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment". Se un file in fase di creazione si trova su un disco su un modulo che gira prima della 17.2, allora viene creato un normale file di stream, e tutto andrà bene con il fallimento che si verifica solo se si cerca di far crescere il file > 2 GB. Quindi permettere alla vostra applicazione Posix di usare file di grandi dimensioni non costa nulla in termini di interoperabilità. La maggior parte dei prodotti Open source supportati da VOS produrrà e tratterà correttamente i file di stream a 64 bit a partire dalla Release 17.2.
Le applicazioni conformi a Posix possono essere facilmente costruite per una grande consapevolezza dei file senza alcuna modifica della sorgente: i nuovi file creati su dischi che girano su moduli 17.2+ saranno file stream a 64 bit (spesso chiamati stream64) e su moduli pre-17.2 saranno file stream ordinari. Le applicazioni che usano l'interfaccia VOS s$ o VOS Language I/O sono chiamate applicazioni native e quelle che usano file stream saranno in grado di accedere ai file stream64 fintanto che non usano operazioni di posizionamento a byte (il posizionamento su BOF o EOF non è considerato posizionamento a byte) O se il file è più piccolo di 2 GB.
- Applicazioni native esistenti
Molte applicazioni native hanno semplicemente bisogno di cambiare l'uso del comando create_file (o s$create_file) per indicare che l'organizzazione è STREAM64 piuttosto che STREAM. Se l'applicazione utilizza operazioni di posizionamento e il file cresce fino a > 2 GB, allora s$seq_position produrrà un errore: per supportare file più grandi, le chiamate s$seq_position devono essere cambiate in s$seq_position_x. Anche in questo caso, l'uso delle interfacce _x non interferisce con la capacità dell'applicazione di fare riferimento ai normali file di flusso esistenti sui moduli che potrebbero non supportare le interfacce _x, fintanto che gli argomenti di posizionamento sono nell'intervallo supportato. Quindi effettuare la modifica permette l'accesso a qualsiasi tipo di file di flusso e non costa nulla in termini di interoperabilità.
Le applicazioni esistenti che utilizzano solo interfacce che non comunicano la posizione dei byte: s$seq_read, s$seq_write, s$seq_position BOF/EOF saranno in grado di gestire i file stream64 senza modifiche. Molte applicazioni sono scritte per trattare con i file ASCII sia che siano sequenziali che stream e quindi non necessitano di modifiche per trattare con i file stream a 64 bit, indipendentemente dalle dimensioni.
I file stream a 64-bit non possono avere indici, e quindi un file stream indicizzato non può essere convertito in stream64. I file stream indicizzati non possono crescere fino a > 2 GB a causa di restrizioni nell'implementazione dell'indice esistente.
- Compatibilità
Poiché i file di flusso a 64 bit offrono una serie di vantaggi, dovrebbero essere adottati quando possibile, se non è richiesto un indice.
Finché il file non cresce > 2 GB, può essere copiato o spostato su moduli che eseguono versioni precedenti di VOS, e vi apparirà come un normale file di flusso. Si può anche spostare un disco contenente file stream64 in un VOS più vecchio, a condizione che i file non siano "limitati". Un file è limitato quando cresce > 2 GB o è scarsamente allocato; tali file non possono essere aperti se il disco che li contiene viene spostato su un VOS pre-17.2 (sono disponibili strumenti per identificare i file limitati se si sta pianificando un tale spostamento). Tuttavia, le applicazioni che eseguono versioni precedenti di VOS possono aprire, leggere e scrivere qualsiasi tipo di file stream64 attraverso la rete; qualsiasi errore che si verifica è lo stesso come se l'applicazione fosse in esecuzione su 17.2+ (per esempio, l'uso di s$seq_position per il posizionamento dei byte quando il file supera i 2 GB).
- Prodotti Open Source
La maggior parte dei software aperti supportati su VOS è stata convertita in file di grandi dimensioni, ad esempio ftp, sftp, samba, ecc. Questo ha alcune implicazioni. A partire dalla release 17.2, è ora possibile ftp un file stream su VOS e non preoccuparsi che il file sia troppo grande poiché il demone ftp creerà un file stream64. ftp scrive tutti i byte e quindi il file risultante non sarà scarso (vedi sezione successiva), anche se composto per lo più da zeri binari. La semplice copia del file trasferito può ridurre notevolmente lo spazio su disco che occupa. Se si prevede di aggiungere un indice al file ftp'ed, è necessario prima convertirlo in un normale file stream (e naturalmente non deve superare i 2 GB di lunghezza).
Assegnazione rada
I blocchi che contengono tutti gli zeri binari non sono sempre allocati per i file stream64 e quindi non richiedono spazio su disco. Il comando gnu "truncate" (in >sistema>gnu_library>bin) può essere usato sia per troncare che per estendere la dimensione di un file stream. In 18.0, VOS fornisce un comando simile chiamato reset_eof. I dati oltre EOF non sono definiti, ma quando EOF è esteso, il contenuto del file dal punto dell'EOF corrente è sempre impostato a zeri binari.
Si consideri un normale file stream e un file stream64:
creare_file stm -organizzazione del flusso
create_file s64 -organizzazione del flusso64
e supponiamo che ognuno di essi abbia un contenuto "abc". Vogliamo estendere i file in modo che ciascuno occupi 2 miliardi di byte:
bash
bash-4.2$ troncato -s 2000000000 s64
bash-4.2$ troncato -s 2000000000 stm
La prima richiesta termina immediatamente, mentre la seconda dura diversi minuti. I file mostrano l'equivalenza logica:
bash-4.2$ ls -l
totale 244382
-rwxrwxrwxrwx 1 nessuno nessuno nessuno 2000000000 25 feb 14:08 s64
-rwxrwxrwxrwx 1 nessuno nessuno nessuno 2000000000 25 feb 14:11 stm
Tuttavia, il numero di blocchi del disco che ogni file occupa è molto diverso, come mostra il comando VOS list:
elenco
I file: 2, Blocchi: 488764
w 4 s64
w 488760 stm
Nella release 18.0, le operazioni equivalenti possono utilizzare il comando VOS reset_eof:
reset_di s64 200000000000
Il comando VOS avvisa se si chiede di estendere un normale file di flusso di più di qualche migliaio di blocchi, poiché si tratta di un'operazione così costosa
reset_di stm 200000000000
Estendendo eof a 200000000000 si aggiungono 488281 blocchi al file. Vuoi estendere stm entro 199999999996 byte? (sì, no)
Ecco il file stream a 64 bit dopo essere stato esteso. Esso consiste di soli due blocchi di dati:
dump_file s64
Blocco numero 1
000 6162630A 000000000000 000000000000 0000000000 |abc............................
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Numero di blocco 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Il dump del file di flusso ordinario stm mostrerà tutti i 488282 blocchi che sono stati assegnati con la maggior parte dei blocchi contenenti zeri binari.
dump_file stm
Blocco numero 1
000 6162630A 000000000000 000000000000 0000000000 |abc............................
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Blocco numero 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Blocco numero 3
…
Numero di blocco 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFF FFFFFFFFFFFF |...............................................
=
FF0 FFFFFFFFFFFFFF FFFFFFFFFFFFFF FFFFFFFFFFFF FFFFFFFFFFFF FFFFFFFFFF |.............................................
Tuttavia, confrontare i file_file e diff vedono i file come equivalenti, ma è necessario leggere tutti i blocchi nel file di flusso ordinario che in questo caso può richiedere alcuni minuti:
pronto;confronta_file s64 stm
pronto 14:29:47
pronto 14:31:24 45.877 46
Conversione dei file
Il comando convert_stream_file è disponibile per convertire tra uno qualsiasi dei tipi di file sequenziali e di flusso (flusso, flusso a 64 bit, sequenziale e sequenziale esteso) e per modificare le estensioni. Tipicamente la conversione comporta la copia del contenuto del file e in questo modo è simile alla creazione di un file di destinazione vuoto e all'utilizzo di copy_file con l'opzione -truncate. convert_stream_file può essere utilizzato per modificare il file in posizione e ha il vantaggio di assicurarsi che il contenuto esistente possa essere rappresentato nel nuovo formato richiesto prima di tentare la conversione.
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 <<<<<
Allora:
convert_stream_file_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
Il file risultante viene mostrato come ristretto (64-bit/rstr) a causa della sua scarsità. Anche il comando copy_file produrrà un file rado. Convertendo un file stream64 in un file stream ordinario, tutti i blocchi saranno istanziati e quindi il file risultante può essere considerevolmente più grande dell'originale.
In un file stream64, non c'è garanzia che un blocco che contiene zeri binari sia allocato o meno su disco. Per esempio, se si scrivono alcuni zeri in un blocco che poi finisce per essere tutti gli zeri, il blocco rimane allocato - o se un programma scrive esplicitamente zero dati riempiendo i blocchi. Solo i blocchi che non vengono mai scritti rimangono non allocati; copy_file e convert_stream_file non scrivono mai blocchi contenenti tutti gli zeri binari.
Caratteristiche fisiche
- Estensioni
L'effettivo limite di crescita di qualsiasi file VOS è determinato dalla sua estensione, quindi è importante capire cosa sia un'estensione. La mappa dei file VOS contiene gli indirizzi dei dischi per ogni blocco di 4k di un file; è limitata a 523792 voci e quindi ogni file senza estensione è limitato a 2145452032 (523792 * 4096) byte. Questo è leggermente inferiore a 2**31 e quindi è il limite effettivo per la crescita di un normale file di flusso.
Un'estensione è un gruppo di N blocchi contigui su disco, dove N è la dimensione dell'estensione. La mappa del file per un file allocato tramite extents contiene l'indirizzo del primo blocco nell'estensione e quindi permette alla mappa del file di rappresentare un file significativamente più grande. Le estensioni allocate dinamicamente consentono dimensioni di estensione fino a 256 consentendo un file contenente 512 GB (Nota: le estensioni allocate staticamente che consentono dimensioni di estensione superiori a 256 sono deprecate ad eccezione dell'uso con i file di paginazione; queste hanno molte restrizioni e problemi di prestazioni che rendono poi inaccettabili per l'uso generale).
Per poter crescere oltre i 2 GB, un file stream64 deve avere delle estensioni, il cui valore determinerà il suo limite di crescita effettivo. Per esempio,
create_file stm64 -organizzazione vapore64 -extent_size 32
creerà un file che può crescere fino a 64 GB.
Nella release 17.2, la dimensione predefinita di estensione per i file creati da Posix Runtime è 8, consentendo una crescita fino a 16 GB. Tali file crescono di 8 blocchi alla volta, e quindi la dimensione minima di qualsiasi file è di 8 blocchi. Questo valore predefinito può essere modificato da un amministratore di sistema per modulo, ma più grande è il potenziale di crescita, più grande è la dimensione minima di un file. Estensioni maggiori possono essere un problema per le applicazioni che producono molti file molto piccoli.
- Come le estensioni influiscono sulla scarsa allocazione
Normalmente i blocchi che non sono mai scritti non sono allocati per i file stream64; tuttavia se un blocco in una misura è scritto, allora tutti i blocchi in quella misura sono allocati, anche se alcuni contengono tutti gli zeri binari.
Supponiamo che un file non esteso contenente la stringa abc (stm1) venga convertito in un file di dimensione 8 (stm8):
dump_file stm1
Blocco numero 1
000 6162630A 000000000000 000000000000 0000000000 |abc............................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |.................................................
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
Blocco numero 1
000 6162630A 000000000000 000000000000 0000000000 |abc............................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |.................................................
Blocco numero 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Blocco numero 3
…
Blocco numero 8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |.................................................
L'opzione -brief è stata aggiunta a dump_file nella release 18.0 e può essere utile quando non si vogliono vedere i blocchi che sono fisicamente presenti, ma rappresentano blocchi "vuoti" (potenzialmente inesistenti). L'uso di questa opzione con il file DAE-8 è mostrato di seguito:
dump_file stm8 -brief
Blocco numero 1
000 6162630A 000000000000 000000000000 0000000000 |abc............................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |.................................................
Questo è efficace anche nel nascondere i blocchi "vuoti" contenenti tutti i -1 per i relativi file fissi.
- Estensioni flessibili
Nella release 18.0 sono state introdotte delle estensioni flessibili che permettono ad un piccolo file di crescere un blocco alla volta; man mano che il file si ingrandisce, il valore dell'estensione cambia. Questo è il valore predefinito per tutti i file creati dalle applicazioni Posix nella Release 18.0 ed è quello che si ottiene con il comando create_file se non si dà una specifica dimensione di estensione:
create_file flex -organizzazione stream64 -extent_size
I file con estensioni flessibili sono chiamati file flessibili; solo i file stream64 possono avere estensioni flessibili. Il comando display_file_status mostra la dimensione dell'estensione di un file flex come "flex".
display_file_status flex
nome: %swsle#Raid4>flex
organizzazione dei file: file stream (64 bit)
modificato l'ultima volta a: 15-02-25 12:06:25 est
…
Estensioni dinamiche: sì
dimensione dell'estensione: flex
Se il comando display_file_status viene eseguito su un modulo pre-18.0, viene visualizzato:
dimensione dell'estensione: -1
Se un file flex viene copiato su un disco in un modulo 17.2, ha delle estensioni che sono le predefinite per quel modulo. Se copiato su 17.1 o prima, il risultato è un normale file stream.
Nella versione 17.2+, compare_files non vede le differenze di dimensione tra i file di stream, e i file appaiono identici indipendentemente dalle estensioni. Per esempio, supponiamo che %swsle#m109_mas sia un modulo con 17.2:
copy_file flex %swsle#m109_mas>Stratus
confrontare i file flex %swsle#m109_mas>Stratus>flex
pronto 14:42:38 0,001 6
L'esecuzione di compar_files su un modulo pre-17.2 lo mostrerà come una differenza:
confrontare i file %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex non corrisponde a B (%swsle#m109_mas>Stratus>flex).
- Alcuni attributi dei due file non corrispondono:
misura -1 8
I file Flex sono in grado di contenere un po' meno di 512 GB, in particolare 540.142.534.656 byte contro i 549.235.720.192 con DAE-256, ma hanno il vantaggio che i file piccoli crescono un blocco alla volta, poi 8, poi 32, poi 256 rispetto ai sempre 256 blocchi alla volta.
Non si dovrebbe montare un disco contenente file flex su un modulo pre-18.0; esistono strumenti che permettono di esaminare facilmente un disco per verificare la presenza di file flex. Se lo fate accidentalmente, i file non saranno visibili e non saranno accessibili. Tali file o qualsiasi directory che li contenga non possono essere cancellati e quindi rimarranno intatti se il disco viene spostato di nuovo in un modulo con 18.0+. Tuttavia, se si effettua il salvataggio su un modulo pre-18.0, tutti i file flex saranno eliminati e lo spazio recuperato.
Strumenti
- Individuare i file di flusso a 64 bit su un modulo
Quando è necessario spostare un disco in una versione precedente di VOS, è necessario individuare i file che sono incompatibili con la versione precedente. Un comando è disponibile per aiutare in questo senso:
localizzare i file_stream_files -form
-------------- localizzare i file_stream_files ---------------
nomi_directory:
-profondità:
-tipo: 64-bit
-Breve: no
-lungo: no
-tipo può anche essere flessibile, rado, o grande (che individuerà i file di flusso a 64 bit con quella specifica caratteristica), o tutti (che individuerà tutti i file di flusso).
A seconda della profondità, vengono cercate le directory subordinate e se il file ha uno degli attributi (non specificato per tipo), vengono mostrate anche le informazioni relative a questo e le dimensioni. Se non viene dato un nome alla directory, allora tutti i dischi del modulo vengono cercati dalla root. Per esempio:
locate_stream_files -tipo 64-bit
Controllo delle directory sul disco %swsle#raid0-1...
%swsle#raid0-1:
smb_test.stm64 (FLEX/grande)
smb_test.stmb
Totale di 2 file di flusso a 64 bit.
Controllo delle directory sul disco %swsle#raid0-2...
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/grande)
Totale di 3 file di flusso a 64 bit.
Controllo delle directory sul disco %swsle#Raid4...
%swsle#Raid4>otto:
b3 (DAE-8)
grande (DAE-256/grande/sparso)
…
- Confronti a blocchi
Nelle release 17.2 e 18.0, sono disponibili nuove opzioni per il comando compare_files che sono utili per i file di stream. Il confronto blocco per blocco dei tipi di file strutturati di VOS non è tipicamente utile perché due blocchi con valori diversi spesso rappresentano gli stessi record logici. Per esempio, i dati non utilizzati nei record di un file relativo oltre la loro lunghezza attuale sono imprevedibili. Inoltre, i file sequenziali contengono byte di riempimento non definiti. Il contenuto dei blocchi dei file sequenziali estesi è completamente diverso se la dimensione del record è diversa, anche se rappresenta gli stessi record logici.
Tuttavia, i confronti a blocchi possono talvolta essere utili per i file fissi e per i file di flusso. Il problema è che compare_files è orientato ai record e progettato per mostrare le differenze in termini di numeri di record (o numeri di riga) che possono essere localizzati usando un editor. Questo ha presentato problemi per i file di flusso binario che non sono organizzati in termini di record. Poiché la dimensione dei record per qualsiasi file è limitata a 32767 byte, utilizzando s$seq_read in un file di flusso quando si verifica una sequenza di più di 32k byte senza che intervenga un delimitatore di record della NL, si ottengono i successivi 32767 caratteri, senza distinguere se il byte successivo è una NL o meno. Ciò rende ambiguo il risultato di un confronto orientato ai record per i file di flusso che contengono valori binari piuttosto che una sequenza di caratteri separati dal carattere NL.
Questo problema è stato affrontato nella versione 17.2; compar_files rileverà i casi in cui un falso successo può essersi verificato in precedenza - in particolare quando 32767 caratteri seguiti da una BN corrispondono a 32767 caratteri non seguiti da una BN. Se ciò si verifica, verrà segnalato un errore che indica che il file stream contiene record > 32767. Se questo non si verifica mai, allora i risultati orientati ai record saranno validi e possono essere attendibili. Ma in ogni caso, quando tutto quello che si vuole fare è assicurare che i file siano identici, il confronto dei blocchi di un file non strutturato è molto più veloce del metodo orientato ai record. Il problema con i confronti a blocchi è che, in assenza di record che servano da guida, il confronto dopo la prima discrepanza è spesso privo di significato.
Nella versione 17.2, l'opzione -compare_blocks è stata aggiunta a questo scopo al comando compare_files. Questo rileverà rapidamente se i file non strutturati sono o meno blocco per blocco identici e identificherà il blocco in cui differiscono. Per il raro caso in cui la differenza è causata da una sovrapposizione (alcuni byte modificati rispetto a quelli inseriti o cancellati) e il resto dei file sono identici, è disponibile anche l'opzione -continue. In questo modo viene mostrato l'intervallo di blocchi nel resto del file che differiscono. Se per esempio è stato inserito un byte (invece di sovrapposto), allora tutti i blocchi rimanenti saranno diversi; cioè, la risincronizzazione come si fa con i confronti dei record non è possibile con i confronti dei blocchi. Ma nel caso a cui si è accennato, questa informazione aggiuntiva potrebbe accertare che l'unica differenza è costituita da alcuni byte sovrapposti in alcuni blocchi, che forse rappresentano qualcosa come un timestamp.
Come esempio di -confronta_blocchi con -continua:
confronta_file flex dae256 -confronta_blocchi -continua
A (%swsle#m111_mas>Stratus>Newman>flex) non corrisponde a B (%swsle#m111_mas>Stratus>Newman>dae256).
- I blocchi di dati da 2 a 24 sono diversi.
- I blocchi di dati da 33 a 488 sono diversi.
- 272 blocchi aggiuntivi nel file B.
- Confronto tra file sparsi
Il comando compare_files guarda tutti i blocchi fisicamente presenti in un file. Questo può essere un problema in file scarsi, perché un blocco di zeri binari può apparire come un blocco allocato in un file, ma non essere presente in un altro. I file possono essere logicamente identici, ma non blocco per blocco. Infatti, utilizzando copy_file si eliminano i blocchi di zeri binari nel target, e se ne esistono, questo garantisce che il sorgente e il target non saranno blocco per blocco identici.
Questo è un problema anche per i file di flusso basati sull'estensione, perché tutti i blocchi in un'estensione sono sempre istanziati anche se contengono tutti gli zeri binari. Ciò significa che i blocchi in un file di estensione rado possono avere un aspetto diverso da quello dei blocchi in un identico file non estensivo, anche se rappresentano esattamente gli stessi dati. L'esecuzione di copy_file non può eliminare i blocchi zero in un'estensione.
L'esempio che mostra l'uso di -continue sopra riguarda in realtà due file identici, tranne che uno ha estensioni DAE-256 e l'altro ha estensioni flessibili.
Quindi un file DAE-8 con contenuto "abc" conterrà un blocco con "abc" seguito da altri 7 blocchi contenenti zeri binari. Un file non extent (o file flex) avrà solo un blocco con "abc", e un file DAE-16 avrà un blocco "abc" seguito da 15 blocchi di zeri binari.
Usando il comando compara_file con -compare_blocchi mostrerà tutti questi file come diversi, anche se tutti rappresentano gli stessi dati del file. Nella release 18.0, l'opzione -compare_all_blocks è disponibile per questa situazione. Questo fa sì che copy_file istanzi logicamente i blocchi mancanti nei file che vengono confrontati, con il risultato di un vero e proprio confronto blocco per blocco con le differenze causate dalla scarsità eliminata. I blocchi mancanti nei file stream64 sono considerati tutti gli zeri binari mentre in fisso (o tutti gli altri tipi di file) sono considerati binari -1′s (tutti FFFF).
In un file molto rado, questo può rendere il confronto molto più lento rispetto all'utilizzo delle opzioni -compare_blocks, ma comunque significativamente più veloce rispetto all'utilizzo del confronto di default orientato ai record. In genere è necessario solo quando si confrontano blocchi di file con estensioni diverse, anche se ci sono altri casi, come detto, in cui la scarsità può essere diversa. Questo è utile anche per i file fissi con estensioni diverse.