Los archivos de flujo VOS tienen un crecimiento limitado a unos 2 GB. Esto se debe a que la definición de interfaces como s$seq_position, s$get_port_status, s$lock_region, etc. utilizan variables de 32 bits con signo para indicar la posición en el archivo y 2**31 es el valor más grande posible que se puede representar. En los archivos de secuencia, la posición es el desplazamiento de bytes en lugar del número de registro como en otras organizaciones de archivos VOS.
Los archivos de flujo de 64 bits están disponibles a partir de la versión 17.2 y permiten un crecimiento limitado únicamente por el sistema de archivos VOS (el tamaño máximo de cualquier archivo es de 512 GB). Además de ampliar el potencial de crecimiento, estos archivos ofrecen otras ventajas, en particular cuando se accede a datos binarios. A diferencia de los archivos de flujo normal, los bloques que contienen todos los ceros binarios no ocupan espacio en el disco, y la lectura de esos datos no requiere acceso al disco.
Las aplicaciones compatibles con Posix se pueden construir fácilmente para la sensibilización de archivos grandes sin ningún cambio en la fuente: los nuevos archivos creados en discos que se ejecutan en módulos de 17.2+ serán archivos de 64 bits (a menudo denominados stream64) y en los módulos anteriores a 17.2 serán archivos stream ordinarios. Las aplicaciones que utilizan la interfaz VOS s$ o la E/S del lenguaje VOS se denominan aplicaciones nativas y las que utilizan archivos de stream64 podrán acceder a ellos siempre y cuando no utilicen operaciones de posicionamiento por bytes (el posicionamiento en BOF o EOF no se considera posicionamiento por bytes) O si el archivo es Sin embargo, tendrán que ser modificados para crear archivos de stream64.
A continuación se ofrece alguna información que puede ser útil si/cuando se planea hacer uso de los archivos de flujo de 64 bits. Está organizada de la siguiente manera:
Aplicaciones existentes y compatibilidad
- Aplicaciones Posix existentes
- Aplicaciones nativas existentes
- Compatibilidad
- Productos de código abierto
Asignación escasa
Conversión de archivos
Características físicas
- Extensiones
- Cómo afectan los alcances a la asignación dispersa
- Extensiones flexibles
Herramientas
- Localizando archivos de 64 bits en un módulo
- El bloque compara
- Comparando los archivos dispersos
Aplicaciones existentes y compatibilidad
- Aplicaciones Posix existentes
A partir de la versión 17.2, las aplicaciones Posix pueden ser construidas para el conocimiento de archivos grandes permitiendo entonces acceder a archivos de 64 bits y crearlos si el objetivo está en un disco que funciona en 17.2 o más. Si la aplicación es compatible con Posix (por ejemplo, está codificada para utilizar tipos como off_t en lugar de int cuando sea necesario), entonces no se necesitan cambios en la fuente; simplemente constrúyala como se describe en el manual de referencia de OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment". Si el archivo que se está creando se encuentra en un disco en un módulo que funciona antes de 17.2, entonces se crea un archivo de flujo normal, y todo estará bien si se produce un fallo sólo si se intenta hacer crecer el archivo > 2 GB. Por lo tanto, permitir que su aplicación Posix utilice archivos grandes no cuesta nada en términos de interoperabilidad. La mayoría de los productos de código abierto compatibles con VOS producen y manejan correctamente archivos de 64 bits a partir de la versión 17.2.
Las aplicaciones compatibles con Posix se pueden construir fácilmente para la sensibilización de archivos grandes sin ningún cambio en la fuente: los nuevos archivos creados en discos que se ejecutan en módulos de 17.2+ serán archivos de flujo de 64 bits (a menudo denominados stream64) y en los módulos anteriores a 17.2 serán archivos de flujo ordinarios. Las aplicaciones que utilizan la interfaz VOS s$ o la E/S del lenguaje VOS se denominan aplicaciones nativas y las que utilizan archivos de streaming podrán acceder a los archivos de stream64 siempre y cuando no utilicen operaciones de posicionamiento de bytes (el posicionamiento en BOF o EOF no se considera posicionamiento de bytes) O si el archivo es menor de 2 GB.
- Aplicaciones nativas existentes
Muchas aplicaciones nativas simplemente necesitan cambiar el uso del comando create_file (o s$create_file) para indicar que la organización es STREAM64 en lugar de STREAM. Si la aplicación utiliza operaciones de posicionamiento y el archivo crece a > 2 GB, entonces s$seq_position producirá un error: para soportar archivos más grandes, las llamadas a s$seq_position deben cambiarse a s$seq_position_x. Una vez más, el uso de interfaces _x no interfiere con la capacidad de la aplicación para hacer referencia a los archivos de flujo normales existentes en los módulos que pueden no soportar las interfaces _x, siempre que los argumentos de posición estén en el rango soportado. Por lo tanto, realizar el cambio permite el acceso a cualquier tipo de archivo de flujo y no cuesta nada en cuanto a la interoperabilidad.
Las aplicaciones existentes que utilizan sólo interfaces que no comunican la posición de los bytes: s$seq_read, s$seq_write, s$seq_position BOF/EOF podrán tratar con archivos stream64 sin modificación. Muchas aplicaciones están escritas para tratar con archivos ASCII ya sean secuenciales o de streaming y por lo tanto no necesitan ningún cambio para tratar con archivos de streaming de 64 bits, independientemente de su tamaño.
Los archivos de streaming de 64 bits no pueden tener índices, por lo que un archivo de streaming indexado no puede ser convertido a stream64. Los archivos streaming indexados no pueden crecer a > 2 GB debido a restricciones en la implementación de índices existentes.
- Compatibilidad
Dado que los archivos de flujo de 64 bits ofrecen una serie de ventajas, deben adoptarse cuando sea posible, si no se requiere un índice.
Mientras el archivo no crezca > 2 GB, puede ser copiado o movido a módulos que ejecuten versiones antiguas de VOS, y aparecerá allí como un archivo de flujo normal. Incluso se puede mover un disco que contenga archivos stream64 a un VOS más antiguo, siempre que los archivos no estén "restringidos". Un archivo está restringido cuando crece > 2 GB o está escasamente asignado; tales archivos no pueden abrirse si el disco que los contiene se mueve a una VOS anterior a la 17.2 (hay herramientas disponibles para identificar archivos restringidos si se planea tal movimiento). Sin embargo, las aplicaciones que ejecutan versiones anteriores de VOS pueden abrir, leer y escribir cualquier tipo de archivos stream64 a través de la red; cualquier fallo que se produzca es el mismo que si la aplicación se ejecutara en 17.2+ (por ejemplo, el uso de s$seq_position para el posicionamiento de bytes cuando el archivo supera los 2 GB).
- Productos de código abierto
La mayoría del software abierto soportado en VOS ha sido convertido para ser consciente de los archivos grandes, por ejemplo ftp, sftp, samba, etc. Eso tiene ciertas implicaciones. A partir de la versión 17.2, ahora se puede ftp un archivo de stream a VOS y no preocuparse de que el archivo sea demasiado grande ya que el demonio ftp creará un archivo stream64. ftp escribe todos los bytes y por lo tanto el archivo resultante no será escaso (véase la siguiente sección), aunque consista en su mayoría de ceros binarios. El simple hecho de copiar el archivo transferido puede reducir enormemente el espacio de disco que ocupa. Si planea agregar un índice al archivo ftp, primero debe convertirlo en un archivo corriente ordinario (y por supuesto no debe exceder los 2 GB de longitud).
Asignación escasa
Los bloques que contienen todos los ceros binarios no siempre se asignan a los archivos de stream64 y por lo tanto no requieren espacio en el disco. El comando gnu "truncado" (en >sistema>bin_librería_gnu) puede ser usado tanto para truncar como para extender el tamaño de un archivo de stream. En 18.0, VOS proporciona un comando similar llamado reset_eof. Los datos pasados EOF no están definidos, pero cuando se extiende EOF, el contenido del archivo desde el punto del EOF actual siempre se establece en ceros binarios.
Considere un archivo de stream ordinario y un archivo de stream64:
create_file stm -organization stream
create_file s64 -organización stream64
y asumir que cada uno tiene un contenido "abc". Deseamos extender los archivos de manera que cada uno ocupe 2 mil millones de bytes:
bash
bash-4.2$ truncado -s 2000000000 s64
bash-4.2$ truncado -s 2000000000 stm
La primera petición termina inmediatamente mientras que la segunda tarda varios minutos. Los archivos muestran una equivalencia lógica:
bash-4.2$ ls -l
total 244382
-rwxrwxrwx 1 nobody nobody 2000000000 Feb 25 14:08 s64
-rwxrwxrwx 1 nobody nobody 2000000000 Feb 25 14:11 stm
Sin embargo, el número de bloques de disco que ocupa cada archivo es bastante diferente, como se muestra en el comando de lista de VOS:
lista
Archivos: 2, Bloques: 488764
w 4 s64
w 488760 stm
En la versión 18.0, las operaciones equivalentes pueden usar el comando VOS reset_of:
reset_of s64 2000000000
El comando VOS avisará si pide extender un archivo de flujo ordinario por más de unos pocos miles de bloques, ya que es una operación muy costosa.
reset_of stm 2000000000
Extendiendo eof a 2000000000 añadirá 488281 bloques al archivo. ¿Quieres extender stm en 1999999996 bytes? (sí, no)
Aquí está el archivo de flujo de 64 bits después de haber sido extendido. Consiste en sólo dos bloques de datos:
dump_file s64
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc...................
=
FF0 00000000 00000000 00000000 00000000...
Número de bloque 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
El volcado del archivo de flujo ordinario stm mostrará todos los bloques 488282 que han sido asignados con la mayoría de los bloques que contienen ceros binarios.
dump_file stm
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc...................
=
FF0 00000000 00000000 00000000 00000000...
Bloque número 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
Bloque número 3
…
Número de bloque 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |...
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFFFF FFFFFFFF FFFFFFFF |...
No obstante, compare_files y diff ven los archivos como equivalentes, pero necesitan leer a través de todos los bloques en el archivo de flujo ordinario, lo que en este caso puede llevar unos minutos:
ready;compare_files s64 stm
listo 14:29:47
listo 14:31:24 45.877 46
Conversión de archivos
El comando convert_stream_file está disponible para convertir entre cualquiera de los tipos de archivo secuencial y de flujo (flujo, flujo de 64 bits, secuencial y secuencial extendido) y para cambiar los extents. Típicamente la conversión implica copiar el contenido del archivo y de esta manera es similar a crear un archivo de destino vacío y usar copy_file con la opción -truncate. convert_stream_file puede usarse para cambiar el archivo en su lugar y tiene la ventaja de asegurar que el contenido existente puede ser representado en el nuevo formato solicitado antes de intentar la conversión.
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 <<<<<
Entonces..:
convert_stream_file stm -a 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
El archivo resultante se muestra como restringido (64-bit/rstr) debido a que ahora es escaso. El comando copiar_fichero también producirá un archivo escaso. Convertir un archivo de stream64 a un archivo de stream ordinario resultará en que todos los bloques se instancien y por lo tanto el archivo resultante puede ser considerablemente más grande que el original.
En un archivo stream64, no hay garantía de que un bloque que por casualidad contenga ceros binarios sea asignado en el disco o no. Por ejemplo, si se escriben algunos ceros en un bloque que luego termina siendo todos ceros, el bloque permanece asignado - o si un programa escribe explícitamente cero datos llenando bloques. Sólo los bloques que nunca se escriben permanecen sin asignar; copy_file y convert_stream_file nunca escriben bloques que contengan todos los ceros binarios.
Características físicas
- Extensiones
El límite de crecimiento real de cualquier archivo VOS está determinado por el tamaño de su extensión, por lo que es importante entender qué es una extensión. El mapa de archivos VOS contiene direcciones de disco para cada bloque de 4k en un archivo; está limitado a 523792 entradas y por lo tanto cualquier archivo sin extensión está limitado a 2145452032 (523792 * 4096) bytes. Esto es ligeramente inferior a 2**31 y por lo tanto es el límite real del crecimiento de un archivo de flujo ordinario.
Una extensión es un grupo de N bloques contiguos en el disco, donde N es el tamaño de la extensión. El mapa de archivos de un archivo asignado a través de los extent contiene la dirección del primer bloque en el extent y, por lo tanto, permite que el mapa de archivos represente un archivo significativamente más grande. Los extents asignados dinámicamente permiten un tamaño de extensión de hasta 256, lo que permite un archivo de 512 GB (Nota: los extents asignados estáticamente que permiten un tamaño de extensión superior a 256 son obsoletos, salvo para su uso con archivos de paginación; éstos tienen muchas restricciones y problemas de rendimiento que los hacen inaceptables para el uso general).
Para crecer más allá de 2 GB, un archivo stream64 debe tener extensiones, cuyo valor determinará su límite de crecimiento real. Por ejemplo,
create_file stm64 -organization steam64 -extent_size 32
creará un archivo que puede crecer hasta 64 GB.
En la versión 17.2, el tamaño de extensión predeterminado para los archivos creados por Posix Runtime es 8, lo que permite un crecimiento de hasta 16 GB. Tales archivos crecen 8 bloques a la vez, y por lo tanto el tamaño mínimo de cualquier archivo es de 8 bloques. Este valor predeterminado puede ser modificado por un administrador de sistemas por módulos, pero cuanto mayor sea el potencial de crecimiento, mayor será el tamaño mínimo de un archivo. Los tamaños más grandes pueden ser un problema para las aplicaciones que producen muchos archivos muy pequeños.
- Cómo afectan los alcances a la asignación dispersa
Normalmente los bloques que nunca se escriben no se asignan para los archivos stream64; sin embargo, si se escribe un bloque en una extensión, se asignan todos los bloques en esa extensión, incluso si algunos contienen todos los ceros binarios.
Supongamos que un archivo sin extensión que contiene la cadena abc (stm1) se convierte en un archivo con extensión de tamaño 8 (stm8):
dump_file stm1
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc...................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc...................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
Bloque número 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
Bloque número 3
…
Bloque número 8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
La opción -brief se añadió a dump_file en la versión 18.0 y puede ser útil cuando no se quieren ver los bloques que están físicamente presentes, sino que representan bloques "vacíos" (potencialmente inexistentes). A continuación se muestra cómo utilizar esa opción con el archivo DAE-8:
dump_file stm8 -brief
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc...................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000...
Esto es efectivo también para ocultar los bloques "vacíos" que contienen todo -1′s para parientes de archivos fijos.
- Extensiones flexibles
En la versión 18.0 se introdujeron extensiones flexibles que permiten que un archivo pequeño crezca un bloque a la vez; a medida que el archivo crece, el valor de la extensión cambia. Este es el valor predeterminado para todos los archivos creados por las aplicaciones Posix en la versión 18.0 y es lo que obtendrás con el comando create_file si no das un tamaño de extensión específico:
create_file flex -organization stream64 -extent_size
Los archivos con extensiones flexibles se denominan archivos flexibles; sólo los archivos stream64 pueden tener extensiones flexibles. El comando display_file_status muestra el tamaño de extensión de un archivo flex como "flex".
display_file_status flex
nombre: %swsle#Raid4>flex
organización del archivo: archivo de flujo (64-bit)
modificado por última vez en: 15-02-25 12:06:25 est
…
Extensiones dinámicas: sí
tamaño de la extensión: flex
Si el comando display_file_status se ejecuta en un módulo anterior a 18.0, se muestra:
tamaño de la extensión: -1
Si un archivo flex se copia en un disco en un módulo 17.2, tiene extensiones que son las predeterminadas para ese módulo. Si se copia a 17.1 o antes, el resultado es un flujo de archivos ordinario.
En la versión 17.2+, compare_files no ve diferencias de tamaño de extensión entre los archivos de streaming, y los archivos parecen idénticos independientemente de la extensión. Por ejemplo, supongamos que %swsle#m109_mas es un en un módulo que corre 17.2:
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
listo 14:42:38 0.001 6
Ejecutar compare_files en un módulo pre-17.2 mostrará esto como una diferencia:
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex no coincide con B (%swsle#m109_mas>Stratus>flex).
- Algunos atributos de los dos archivos no coinciden:
tamaño de la extensión -1 8
Los archivos Flex son capaces de contener algo menos de 512 GB, concretamente 540.142.534.656 bytes frente a 549.235.720.192 con DAE-256, pero tienen la ventaja de que los archivos pequeños crecen un bloque cada vez, luego 8, luego 32, luego 256, frente a los siempre 256 bloques cada vez.
No debe montar un disco que contenga archivos flex en un módulo anterior a 18.0; hay herramientas que permiten examinar fácilmente un disco para detectar la presencia de archivos flex. Si lo haces accidentalmente, los archivos no serán visibles y no se podrá acceder a ellos. Tales archivos o cualquier directorio que los contenga no pueden ser borrados y por lo tanto permanecerán intactos si el disco es movido de nuevo a un módulo que corra 18.0+. Sin embargo, si se recupera en un módulo anterior a 18.0, se eliminarán todos los archivos flex y se recuperará el espacio.
Herramientas
- Localizando archivos de 64 bits en un módulo
Cuando se necesita mover un disco a una versión antigua de VOS, hay que localizar los archivos que son incompatibles con la versión antigua. Un comando está disponible para ayudar con esto:
locate_stream_files -form
---------- locate_stream_files ---------
nombres_de_directorio:
-profundidad:
-tipo: 64-bit
-informe: no
-largo: no
-también puede ser flexible, disperso o grande (que localizará los archivos de flujo de 64 bits con esa característica específica), o todos (que localizará todos los archivos de flujo).
En función de la profundidad, se buscan los directorios subordinados y si el archivo tiene alguno de los atributos (no especificados por el tipo), se muestra también la información relativa a eso y al tamaño de la extensión. Si no se da un nombre de directorio, entonces se buscan todos los discos del módulo desde la raíz. Por ejemplo:
locate_stream_files -type 64-bit
Comprobando los directorios en el disco %swsle#raid0-1...
Sleepy, miedo, 1:
smb_test.stm64 (FLEX/large)
smb_test.stmb
Un total de 2 archivos de 64 bits.
Comprobando los directorios del disco %swsle#raid0-2...
Sleepleepsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/grande)
Un total de 3 archivos de 64 bits.
Comprobando los directorios del disco %swsle#Raid4...
Sleep#Raid4>otto:
b3 (DAE-8)
grande (DAE-256/grande/espacio)
…
- El bloque compara
En las versiones 17.2 y 18.0, hay nuevas opciones disponibles para el comando compare_files que son útiles para los archivos de streaming. La comparación bloque a bloque de tipos de archivos estructurados de VOS no suele ser útil porque dos bloques con valores diferentes suelen representar los mismos registros lógicos. Por ejemplo, los datos no utilizados en los registros de un archivo relativo más allá de su longitud actual son impredecibles. Además, los archivos secuenciales contienen bytes de relleno no definidos. El contenido de los bloques de los archivos secuenciales ampliados es completamente diferente si el tamaño del registro es distinto, aunque representen los mismos registros lógicos.
Sin embargo, las comparaciones de bloques pueden ser útiles a veces para los archivos fijos y de flujo. El problema es que compare_files está orientado a los registros y está diseñado para mostrar las diferencias en términos de números de registro (o números de línea) que pueden ser localizados usando un editor. Esto ha planteado problemas para los archivos binarios de secuencia que no están organizados en términos de registros. Dado que el tamaño de los registros de cualquier archivo está limitado a 32767 bytes, el uso de s$seq_read en un archivo de secuencia cuando se produce una secuencia de más de 32k bytes sin que intervenga un delimitador de registro NL entregará los siguientes 32767 caracteres, y no distinguirá si el siguiente byte era un NL o no. Esto hace que el resultado de la comparación orientada a los registros sea ambiguo en el caso de los archivos de secuencia que contienen valores binarios en lugar de una secuencia de caracteres separados por el carácter NL.
Este problema se ha tratado en la versión 17.2; compare_files detectará los casos en los que puede haber habido falsos éxitos anteriormente, concretamente cuando 32767 caracteres seguidos de una NL coincidan con 32767 caracteres no seguidos de una NL. Si esto ocurre, se informará de un error que indica que el archivo de flujo contiene registros > 32767. Si esto nunca ocurre, entonces los resultados orientados a los registros serán válidos y se puede confiar en ellos. Pero en cualquier caso, cuando lo único que se quiere hacer es asegurarse de que los archivos son idénticos, la comparación de los bloques de un archivo no estructurado es mucho más rápida que el método orientado a los registros. El problema de las comparaciones de bloques es que, al no haber registros que sirvan de guía, la comparación después de la primera discrepancia suele carecer de sentido.
En la versión 17.2, la opción -compare_blocks fue añadida al comando compare_files para este propósito. Esto detectará rápidamente si los archivos no estructurados son idénticos bloque por bloque e identificará el bloque en el que difieren. En el caso poco frecuente de que la diferencia se deba a una superposición (se modifican ciertos bytes en lugar de insertarlos o eliminarlos) y el resto de los archivos sean idénticos, también está disponible la opción -continuar. Esto le mostrará el rango de bloques en el resto del archivo que difieren. Si, por ejemplo, se ha insertado un byte (en lugar de superponerlo), entonces todos los bloques restantes serán diferentes; es decir, la resincronización como se hace con las comparaciones de registros no es posible con las comparaciones de bloques. Pero en el caso aludido, esta información adicional podría determinar que la única diferencia son algunos bytes superpuestos en unos pocos bloques, que tal vez representen algo así como una marca de tiempo.
Como ejemplo de -comparar_bloques con -continuar:
compare_files flex dae256 -compare_blocks -continuar
A (%swsle#m111_mas>Stratus>Newman>flex) no coincide con B (%swsle#m111_mas>Stratus>Newman>dae256).
- Los bloques de datos del 2 al 24 difieren.
- Los bloques de datos de 33 a 488 difieren.
- 272 bloques adicionales en el archivo B.
- Comparando los archivos dispersos
El comando compare_files mira todos los bloques físicamente presentes en un archivo. Esto puede ser un problema en los archivos dispersos, porque un bloque de ceros binarios puede aparecer como un bloque asignado en un archivo, pero no estar presente en otro. Los archivos pueden ser lógicamente idénticos, pero no bloque por bloque. De hecho, el uso de copy_file eliminará bloques de ceros binarios en el destino, y si existe alguno, esto garantizará que la fuente y el destino no sean idénticos bloque por bloque.
Esto también es un problema en los archivos de flujo basados en la extensión porque todos los bloques de una extensión siempre se instancian aunque contengan todos los ceros binarios. Esto significa que los bloques de un archivo de extensión dispersa pueden tener un aspecto diferente al de los bloques de un archivo idéntico sin extensión, aunque representen exactamente los mismos datos. Ejecutar el archivo_copia no puede eliminar los bloques de cero en una extensión.
El ejemplo que muestra el uso de -continuar arriba en realidad involucra dos archivos idénticos, excepto que uno tiene extensiones DAE-256 y el otro tiene extensiones flexibles.
Así que un archivo DAE-8 con contenido "abc" contendrá un bloque con "abc" seguido de otros 7 con ceros binarios. Un archivo sin extensión (o archivo flex) sólo tendrá un bloque con "abc", y un archivo DAE-16 tendrá un bloque con "abc" seguido de 15 bloques de ceros binarios.
Usando el comando compare_files con -compare_blocks mostrará todos estos archivos como diferentes, aunque todos ellos representen los mismos datos de archivo. En la versión 18.0, la opción -compare_all_blocks está disponible para esta situación. Esto hace que copy_file instancie lógicamente los bloques que faltan en los archivos que se están comparando, lo que resulta en una verdadera comparación bloque por bloque con las diferencias causadas por la escasez eliminada. Los bloques perdidos en los archivos de stream64 son considerados todos ceros binarios mientras que en los fijos (o todos los otros tipos de archivos) son considerados binarios -1′s (todos FFFF).
En un archivo muy escaso, esto puede hacer que la comparación sea mucho más lenta que el uso de las opciones -compare_blocks, pero aún así significativamente más rápida que el uso de la comparación orientada a registros por defecto. Normalmente sólo se necesita cuando se comparan bloques de archivos que tienen diferentes extensiones, aunque hay otros casos, como se ha mencionado, en los que la dispersión puede ser diferente. Esto también es útil para archivos fijos que tienen diferentes extensiones.