Los archivos de flujo VOS tienen un tamaño máximo de 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., utiliza variables de 32 bits con signo para indicar la posición en el archivo, y 2**31 es el valor máximo que se puede representar. En los archivos de flujo, la posición se indica como desplazamiento en bytes, en lugar de como número de registro, como ocurre en otras estructuras 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, especialmente al acceder a datos binarios. A diferencia de los archivos de flujo normales, los bloques que contienen solo ceros binarios no ocupan espacio en el disco, y la lectura de dichos datos no requiere acceso al disco.
Las aplicaciones compatibles con POSIX pueden configurarse fácilmente para gestionar archivos de gran tamaño sin necesidad de modificar el código fuente: los archivos nuevos creados en discos que funcionen con módulos 17.2 o posteriores serán archivos de 64 bits (a menudo denominados «stream64»), mientras que en módulos anteriores a la versión 17.2 serán archivos de flujo normales. Las aplicaciones que utilizan la interfaz s$ de VOS o VOS Language I/O se denominan aplicaciones nativas, y aquellas que utilizan archivos de flujo podrán acceder a archivos stream64 siempre que no utilicen operaciones de posicionamiento de bytes (el posicionamiento al BOF o al EOF no se considera posicionamiento de bytes) O si el archivo es Sin embargo, deberán modificarse para poder crear archivos stream64.
A continuación te ofrecemos información que te puede resultar útil si tienes pensado utilizar archivos de streaming 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 dispersa
Conversión de archivos
Características físicas
– Extensiones
– Cómo afectan las extensiones a la asignación dispersa
– Extensiones flexibles
Herramientas
– Localización de archivos de flujo de 64 bits en un módulo
– Comparaciones de bloques
– Comparación de archivos dispersos
Aplicaciones existentes y compatibilidad
– Aplicaciones POSIX existentes
A partir de la versión 17.2, las aplicaciones POSIX pueden compilarse con soporte para archivos de gran tamaño, lo que les permite acceder a archivos de 64 bits y crearlos si el destino se encuentra en un disco que ejecuta la versión 17.2 o posterior. Si la aplicación es compatible con POSIX (por ejemplo, está programada para utilizar tipos como off_t en lugar de int cuando sea necesario), no es necesario realizar cambios en el código fuente; basta con compilarla tal y como se describe en el manual de referencia de OpenVOS POSIX.1, R502, «Porting Existing Applications to the 64-bit Stream File Environment» (Portar aplicaciones existentes al entorno de archivos de flujo de 64 bits). Si el archivo que se está creando se encuentra en un disco de un módulo que ejecuta una versión anterior a la 17.2, se creará un archivo de flujo normal y todo irá bien, y solo se producirá un error si se intenta ampliar el archivo a más de 2 GB. Por lo tanto, permitir que su aplicación POSIX utilice archivos de gran tamaño no supone ningún coste en términos de interoperabilidad. La mayoría de los productos de código abierto compatibles con VOS producirán y gestionarán correctamente archivos de flujo de 64 bits a partir de la versión 17.2.
Las aplicaciones compatibles con POSIX pueden configurarse fácilmente para gestionar archivos de gran tamaño sin necesidad de modificar el código fuente: los nuevos archivos creados en discos que funcionen con módulos 17.2 o posteriores serán archivos de flujo de 64 bits (a menudo denominados «stream64»), mientras que en módulos anteriores a la versión 17.2 serán archivos de flujo normales. Las aplicaciones que utilizan la interfaz s$ de VOS o VOS Language I/O se denominan aplicaciones nativas, y aquellas que utilizan archivos de flujo podrán acceder a archivos stream64 siempre que no utilicen operaciones de posicionamiento de bytes (el posicionamiento al BOF o al EOF no se considera posicionamiento de bytes) O si el archivo es inferior a 2 GB.
– Aplicaciones nativas existentes
Muchas aplicaciones nativas solo tienen que 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 supera los 2 GB, s$seq_position generará un error: para admitir 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 archivos de flujo normales existentes en módulos que quizá no admitan las interfaces _x, siempre que los argumentos de posición se encuentren dentro del rango admitido. Por lo tanto, realizar el cambio permite el acceso a cualquier tipo de archivo de flujo y no supone ningún coste en cuanto a interoperabilidad.
Las aplicaciones existentes que utilizan únicamente interfaces que no comunican la posición de los bytes (s$seq_read, s$seq_write, s$seq_position BOF/EOF) podrán gestionar archivos stream64 sin necesidad de modificaciones. Muchas aplicaciones están diseñadas para gestionar archivos ASCII, ya sean secuenciales o de flujo, por lo que no requieren ningún cambio para gestionar archivos de flujo de 64 bits, independientemente de su tamaño.
Los archivos de flujo de 64 bits no pueden contener índices, por lo que un archivo de flujo indexado no se puede convertir a stream64. Los archivos de flujo indexados no pueden superar los 2 GB debido a restricciones en la implementación actual del índice.
– Compatibilidad
Dado que los archivos de flujo de 64 bits ofrecen una serie de ventajas, se recomienda utilizarlos siempre que sea posible, siempre que no se requiera un índice.
Siempre que el archivo no supere los 2 GB, se puede copiar o mover a módulos que ejecuten versiones anteriores de VOS, donde aparecerá como un archivo de flujo normal. Incluso se puede trasladar un disco que contenga archivos stream64 a una versión anterior de VOS, siempre que los archivos no estén «restringidos». Un archivo se considera restringido cuando supera los 2 GB o tiene una asignación dispersa; dichos archivos no se pueden abrir si el disco que los contiene se traslada a un VOS anterior a la versión 17.2 (existen herramientas disponibles para identificar los archivos restringidos si tiene previsto realizar dicho traslado). Sin embargo, las aplicaciones que se ejecutan en versiones anteriores de VOS pueden abrir, leer y escribir cualquier tipo de archivo stream64 a través de la red; cualquier fallo que se produzca es el mismo que si la aplicación se ejecutara en la versión 17.2 o superior (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 parte del software de código abierto compatible con VOS se ha adaptado para gestionar archivos de gran tamaño, como por ejemplo ftp, sftp, samba, etc. Esto tiene ciertas implicaciones. A partir de la versión 17.2, ahora puede transferir un archivo de flujo a VOS mediante FTP sin preocuparse de que el archivo sea demasiado grande, ya que el demonio de FTP creará un archivo stream64. El FTP escribe todos los bytes y, por lo tanto, el archivo resultante no será disperso (véase la siguiente sección), incluso si está compuesto principalmente por ceros binarios. El simple hecho de copiar el archivo transferido puede reducir considerablemente el espacio en disco que ocupa. Si tiene previsto añadir un índice al archivo transferido por FTP, primero debe convertirlo a un archivo de flujo ordinario (y, por supuesto, no debe superar los 2 GB de longitud).
Asignación dispersa
Los bloques que contienen solo ceros binarios no siempre se asignan a los archivos stream64 y, por lo tanto, no requieren espacio en disco. El comando «truncate» de GNU (en >system>gnu_library>bin) se puede utilizar tanto para recortar como para ampliar el tamaño de un archivo stream. En la versión 18.0, VOS ofrece un comando similar llamado reset_eof. Los datos más allá del EOF no están definidos, pero cuando se amplía el EOF, el contenido del archivo a partir del punto del EOF actual siempre se establece en ceros binarios.
Pensemos en un archivo de flujo normal y en un archivo de flujo de 64 bits:
create_file stm -organization stream
create_file s64 -organization stream64
y supongamos que cada uno tiene el contenido «abc». Queremos ampliar los archivos para que cada uno ocupe 2000 millones de bytes:
bash
bash-4.2$ truncate -s 2000000000 s64
bash-4.2$ truncate -s 2000000000 stm
La primera solicitud se completa de inmediato, 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 25 feb 14:08 s64
-rwxrwxrwx 1 nobody nobody 2000000000 25 feb 14:11 stm
Sin embargo, el número de bloques de disco que ocupa cada archivo varía considerablemente, tal y como muestra el comando «list» de VOS:
lista
Archivos: 2, Bloques: 488 764
w 4 s64
w 488760 stm
En la versión 18.0, las operaciones equivalentes se pueden realizar mediante el comando VOS reset_eof:
reset_eof s64 2000000000
El comando VOS te avisará si intentas ampliar un archivo de flujo normal en más de unos pocos miles de bloques, ya que se trata de una operación muy costosa
reset_eof stm 2000000000
Ampliar el eof a 2000000000 añadirá 488281 bloques al archivo. ¿Desea ampliar stm en 1999999996 bytes? (sí, no)
Aquí está el archivo de flujo de 64 bits tras haber sido ampliado. Consta únicamente de dos bloques de datos:
archivo_de_volcado s64
Bloque número 1
000 6162630A 00000000 00000000 00000000 |abc………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
Bloque número 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
Si se muestra el contenido del archivo de flujo ordinario «stm», se verán los 488 282 bloques que se han asignado, la mayoría de los cuales 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
…
Bloque número 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
No obstante, compare_files y diff consideran que los archivos son equivalentes, pero necesitan leer todos los bloques del archivo de flujo normal, lo que en este caso puede llevar unos minutos:
listo;compare_files s64 stm
listo 14:29:47
listo 14:31:24 45,877 46
Conversión de archivos
El comando `convert_stream_file` permite convertir entre cualquiera de los tipos de archivo secuencial y de flujo (flujo, flujo de 64 bits, secuencial y secuencial extendido), así como modificar los extensos. Normalmente, la conversión implica copiar el contenido del archivo y, en este sentido, es similar a crear un archivo de destino vacío y utilizar copy_file con la opción -truncate. convert_stream_file se puede utilizar para modificar el archivo in situ y tiene la ventaja de garantizar que el contenido existente se pueda representar 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 <<<<<
A continuación:
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
El archivo resultante aparece como restringido (64-bit/rstr) debido a que ahora es un archivo disperso. El comando `copy_file` también generará un archivo disperso. Al convertir un archivo `stream64` en un archivo `stream` normal, se instanciarán todos los bloques, por lo que 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 contenga ceros binarios vaya a ser asignado en el disco o no. Por ejemplo, si se escriben algunos ceros en un bloque que luego acaba conteniendo solo ceros, el bloque permanece asignado; lo mismo ocurre si un programa escribe explícitamente datos nulos para rellenar bloques. Solo los bloques en los que nunca se ha escrito nada permanecen sin asignar; las funciones copy_file y convert_stream_file nunca escriben bloques que contengan solo ceros binarios.
Características físicas
– Extensiones
El límite real de crecimiento de cualquier archivo VOS viene determinado por el tamaño de sus extensiones, por lo que es importante comprender qué es una extensión. El mapa de archivos VOS contiene direcciones de disco para cada bloque de 4 KB de un archivo; está limitado a 523 792 entradas y, por lo tanto, cualquier archivo sin extensiones está limitado a 2 145 452 032 (523 792 × 4096) bytes. Esto es ligeramente inferior a 2³¹ y, por lo tanto, es el límite real del crecimiento de un archivo de flujo ordinario.
Un extenso es un grupo de N bloques contiguos en el disco, donde N es el tamaño del extenso. El mapa de archivos de un archivo asignado mediante extensos contiene la dirección del primer bloque del extenso, lo que permite que el mapa represente un archivo de tamaño considerablemente mayor. Los extents asignados dinámicamente permiten un tamaño de hasta 256, lo que permite un archivo de 512 GB (Nota: los extents asignados estáticamente que permiten un tamaño superior a 256 están en desuso, salvo para su uso con archivos de paginación; estos tienen muchas restricciones y problemas de rendimiento que los hacen inaceptables para el uso general).
Para que un archivo stream64 pueda superar los 2 GB, 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 llegar a ocupar hasta 64 GB.
En la versión 17.2, el tamaño predeterminado de los extensos para los archivos creados por Posix Runtime es de 8, lo que permite un crecimiento de hasta 16 GB. Estos archivos crecen 8 bloques cada vez, por lo que el tamaño mínimo de cualquier archivo es de 8 bloques. El administrador del sistema puede modificar este valor predeterminado para cada módulo, pero cuanto mayor sea el potencial de crecimiento, mayor será el tamaño mínimo del archivo. Las extensiones más grandes pueden suponer un problema para las aplicaciones que generan muchos archivos muy pequeños.
– Cómo influyen los extents en la asignación dispersa
Normalmente, los bloques en los que nunca se escribe no se asignan en los archivos stream64; sin embargo, si se escribe en un bloque de una extensión, se asignan todos los bloques de esa extensión, aunque algunos contengan solo ceros binarios.
Supongamos que un archivo sin extensión que contiene la cadena «abc» (stm1) se convierte en un archivo con un tamaño de extensión de 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 resultar útil cuando no se desea ver bloques que, aunque están físicamente presentes, 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 también resulta eficaz para ocultar bloques «vacíos» que contienen solo valores de -1 en los archivos relativos o fijos.
– Extensiones flexibles
Los extensos flexibles se introdujeron en la versión 18.0 y permiten que un archivo pequeño aumente de tamaño bloque a bloque; a medida que el archivo crece, el valor del extenso cambia. Este es el valor predeterminado para todos los archivos creados por aplicaciones POSIX en la versión 18.0 y es el resultado que obtendrás con el comando `create_file` si no especificas un tamaño de extenso concreto:
create_file flex -organization stream64 -extent_size
Los archivos con extensiones flexibles se denominan «archivos flex»; solo los archivos stream64 pueden tener extensiones flexibles. El comando display_file_status muestra el tamaño de la extensión de un archivo flex como «flex».
display_file_status flex
nombre: %swsle#Raid4>flex
organización del archivo: archivo de flujo (64 bits)
última modificación: 25-02-15 12:06:25 EST
…
extensiones dinámicas: sí
tamaño de la extensión: flex
Si se ejecuta el comando `display_file_status` en un módulo anterior a la versión 18.0, muestra lo siguiente: `
`
tamaño del extenso: -1
Si se copia un archivo flex en un disco de un módulo 17.2, tendrá los extensores predeterminados para ese módulo. Si se copia en un módulo 17.1 o anterior, el resultado será un archivo de flujo normal.
En la versión 17.2 y posteriores, la función `compare_files` no detecta diferencias en el tamaño de los extensos entre los archivos de flujo, por lo que los archivos parecen idénticos independientemente de los extensos. Por ejemplo, supongamos que %swsle#m109_mas se encuentra en un módulo que ejecuta la versión 17.2:
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
listo 14:42:38 0,001 6
Si se ejecuta «compare_files» en un módulo anterior a la versión 17.2, se mostrará lo siguiente como 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 pueden almacenar algo menos de 512 GB, concretamente 540 142 534 656 bytes frente a los 549 235 720 192 del formato DAE-256, pero tienen la ventaja de que los archivos pequeños crecen de a un bloque cada vez, luego de a 8, luego de a 32 y luego de a 256, en lugar de hacerlo siempre de a 256 bloques de una vez.
No debes montar un disco que contenga archivos Flex en un módulo anterior a la versión 18.0; existen herramientas que te permiten comprobar fácilmente si un disco contiene archivos Flex. Si lo hace accidentalmente, los archivos no serán visibles y no se podrá acceder a ellos. Dichos archivos o cualquier directorio que los contenga no se pueden eliminar, por lo que permanecerán intactos si el disco se vuelve a colocar en un módulo que ejecute la versión 18.0 o superior. Sin embargo, si realiza una recuperación en un módulo anterior a la versión 18.0, todos los archivos flex se eliminarán y se recuperará el espacio.
Herramientas
– Localización de archivos de flujo de 64 bits en un módulo
Cuando necesites migrar un disco a una versión anterior de VOS, debes localizar los archivos que sean incompatibles con esa versión anterior. Existe un comando que te ayudará a hacerlo:
locate_stream_files -form
—————————– locate_stream_files ————————-
directory_names:
-depth:
-type: 64-bit
-brief: no
-long: no
-type también puede ser flex, sparse o large (lo que localizará archivos de flujo de 64 bits con esa característica específica), o all (lo que localizará todos los archivos de flujo).
En función del parámetro -depth, se buscan los directorios subordinados y, si el archivo tiene alguno de los atributos (no especificados por el tipo), también se muestra información al respecto y el tamaño de la extensión. Si no se indica ningún nombre de directorio, se buscan todos los discos del módulo a partir de la raíz. Por ejemplo:
locate_stream_files -tipo 64 bits
Comprobando los directorios del disco %swsle#raid0-1…
%swsle#raid0-1:
smb_test.stm64 (FLEX/large)
smb_test.stmb
Un total de 2 archivos de flujo de 64 bits.
Comprobando los directorios del disco %swsle#raid0-2…
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/large)
Un total de 3 archivos de flujo de 64 bits.
Comprobando los directorios del disco %swsle#Raid4…
%swsle#Raid4>otto:
b3 (DAE-8)
big (DAE-256/large/sparse)
…
– Comparaciones de bloques
En las versiones 17.2 y 18.0, hay nuevas opciones disponibles para el comando `compare_files` que resultan útiles para los archivos de flujo. La comparación bloque a bloque de los tipos de archivos estructurados VOS no suele ser útil, ya que dos bloques con valores diferentes a menudo representan 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 indefinidos. El contenido de los bloques de los archivos secuenciales extendidos es completamente diferente si el tamaño de los registros es distinto, aunque representen los mismos registros lógicos.
Sin embargo, las comparaciones de bloques pueden resultar útiles en ocasiones para archivos fijos y de flujo. El problema es que la función `compare_files` está orientada a registros y diseñada para mostrar diferencias en términos de números de registro (o números de línea), que pueden localizarse mediante un editor. Esto ha planteado problemas con los archivos de flujo binario, que no están organizados en términos de registros. Dado que el tamaño de los registros de cualquier archivo está limitado a 32 767 bytes, el uso de s$seq_read en un archivo de flujo cuando se produce una secuencia de más de 32 kbytes sin un delimitador de registro NL intermedio devolverá los siguientes 32 767 caracteres, sin distinguir si el siguiente byte era un NL o no. Esto hace que el resultado de la comparación orientada a registros sea ambiguo para los archivos de flujo que contienen valores binarios en lugar de una secuencia de caracteres separados por el carácter NL.
Este problema se ha solucionado en la versión 17.2; la función `compare_files` detectará los casos en los que anteriormente pudiera haberse producido un falso positivo, concretamente cuando 32 767 caracteres seguidos de un salto de línea (NL) coinciden con 32 767 caracteres no seguidos de un salto de línea. Si esto ocurre, se notificará un error indicando que el archivo de flujo contiene registros de más de 32 767 caracteres. Si esto nunca ocurre, los resultados orientados a registros serán válidos y fiables. Pero, en cualquier caso, cuando lo único que se desea es asegurarse de que los archivos son idénticos, comparar los bloques de un archivo no estructurado es mucho más rápido que el método orientado a registros. El problema de las comparaciones de bloques es que, al no haber registros que sirvan de referencia, la comparación tras la primera discrepancia suele carecer de sentido.
En la versión 17.2, se añadió la opción -compare_blocks al comando compare_files con este fin. Esto permite detectar rápidamente si los archivos no estructurados son idénticos bloque a bloque e identificar el bloque en el que difieren. Para el caso excepcional en el que la diferencia se deba a una superposición (es decir, que se hayan modificado ciertos bytes en lugar de insertarlos o eliminarlos) y el resto de los archivos sean idénticos, también está disponible la opción -continue. Esto le mostrará el rango de bloques del resto del archivo que difieren. Si se insertó un byte, por ejemplo (en lugar de superponerse), entonces todos los bloques restantes diferirán; es decir, la resincronización, tal y como se realiza con las comparaciones de registros, no es posible con las comparaciones de bloques. Pero en el caso mencionado, esta información adicional podría determinar que la única diferencia eran algunos bytes superpuestos en unos pocos bloques, lo que tal vez representara algo así como una marca de tiempo.
A modo de ejemplo de la opción -compare_blocks junto con -continue:
compare_files flex dae256 -compare_blocks -continue
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 del 33 al 488 difieren.
– 272 bloques adicionales en el archivo B.
– Comparación de archivos dispersos
El comando `compare_files` examina todos los bloques físicamente presentes en un archivo. Esto puede suponer un problema en los archivos dispersos, ya que 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 a bloque. De hecho, el uso de `copy_file` eliminará los bloques de ceros binarios en el destino y, si existieran, esto garantizará que el origen y el destino no sean idénticos bloque a bloque.
Esto también supone un problema en los archivos de flujo basados en extensiones, ya que todos los bloques de una extensión se instancian siempre, incluso si contienen solo 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 que no sea de extensión, aunque representen exactamente los mismos datos. La ejecución de copy_file no permite eliminar los bloques de ceros de una extensión.
El ejemplo anterior, que muestra el uso de -continue, incluye en realidad dos archivos idénticos, salvo que uno tiene extensiones DAE-256 y el otro, extensiones flexibles.
Así pues, un archivo DAE-8 con el contenido «abc» contendrá un bloque con «abc» seguido de otros siete bloques que contienen ceros binarios. Un archivo sin extensión (o archivo flex) tendrá solo un bloque con «abc», y un archivo DAE-16 tendrá un bloque «abc» seguido de quince bloques de ceros binarios.
Si se utiliza el comando `compare_files` con la opción `-compare_blocks`, todos estos archivos se mostrarán como diferentes, aunque todos contengan los mismos datos. 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 da como resultado una comparación verdadera bloque por bloque en la que se eliminan las diferencias causadas por la dispersión. Los bloques que faltan en los archivos stream64 se consideran todos ceros binarios, mientras que en los archivos fijos (o en todos los demás tipos de archivo) se consideran -1 binarios (todos FFFF).
En un archivo muy disperso, esto puede hacer que la comparación sea mucho más lenta que si se utiliza la opción -compare_blocks, pero sigue siendo significativamente más rápida que la comparación predeterminada orientada a registros. Por lo general, solo es necesario cuando se comparan bloques de archivos con extensiones diferentes, aunque hay otros casos, como se ha mencionado, en los que el grado de dispersión puede variar. Esto también resulta útil para archivos fijos con extensiones diferentes.