La croissance des fichiers de flux VOS est limitée à environ 2 Go. En effet, la définition d'interfaces telles que s$seq_position, s$get_port_status, s$lock_region, etc. utilise des variables signées de 32 bits pour indiquer la position dans le fichier et 2**31 est la plus grande valeur possible qui peut être représentée. Dans les fichiers de flux, la position est un décalage d'octets plutôt qu'un numéro d'enregistrement comme dans les autres organisations de fichiers VOS.
Les fichiers de flux 64 bits sont disponibles à partir de la version 17.2 et leur croissance n'est limitée que par le système de fichiers VOS (la taille maximale de tout fichier est de 512 Go). En plus de leur potentiel de croissance, ces fichiers offrent d'autres avantages, notamment lors de l'accès à des données binaires. Contrairement aux fichiers de flux normaux, les blocs contenant tous les zéros binaires n'occupent aucun espace sur le disque, et la lecture de ces données ne nécessite aucun accès au disque.
Les applications conformes à Posix peuvent être facilement conçues pour la reconnaissance de fichiers volumineux sans modification de la source : les nouveaux fichiers créés sur les disques fonctionnant avec les modules 17.2+ seront des fichiers 64 bits (souvent appelés stream64) et ceux créés avec les modules pré-17.2 seront des fichiers stream ordinaires. Les applications qui utilisent l'interface VOS s$ ou les E/S en langage VOS sont appelées applications natives et celles qui utilisent des fichiers stream pourront accéder aux fichiers stream64 tant qu'elles n'utiliseront pas d'opérations de positionnement d'octets (le positionnement sur BOF ou EOF n'est pas considéré comme un positionnement d'octets) OU si le fichier est Cependant, elles devront être modifiées afin de créer des fichiers stream64.
Voici quelques informations qui peuvent être utiles si/quand vous envisagez d'utiliser des fichiers de flux 64 bits. Elles sont organisées comme suit :
Applications existantes et compatibilité
- Applications Posix existantes
- Applications autochtones existantes
- Compatibilité
- Produits à source ouverte
Allocation de ressources
Conversion de fichiers
Caractéristiques physiques
- Étendue
- Comment l'étendue affecte l'allocation des fonds
- Étendues flexibles
Outils
- Localisation des fichiers de flux 64 bits sur un module
- Comparaison des blocs
- Comparaison des fichiers épars
Applications existantes et compatibilité
- Applications Posix existantes
A partir de la version 17.2, les applications Posix peuvent être conçues pour la reconnaissance de fichiers volumineux, ce qui permet d'accéder à des fichiers 64 bits et de les créer si la cible se trouve sur un disque fonctionnant sous la version 17.2 ou supérieure. Si l'application est conforme à Posix (par exemple, est codée pour utiliser des types comme off_t au lieu de int lorsque cela est nécessaire), alors aucune modification de source n'est nécessaire ; il suffit de la construire comme décrit dans le manuel de référence OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment". Si un fichier en cours de création se trouve sur un disque d'un module fonctionnant avant 17.2, alors un fichier de flux normal est créé, et tout ira bien, l'échec ne se produisant que si l'on tente de faire croître le fichier > 2 Go. Ainsi, permettre à votre application Posix d'utiliser des fichiers volumineux ne coûte rien en termes d'interopérabilité. La plupart des produits Open Source supportés par VOS produiront et traiteront correctement les fichiers de flux 64 bits à partir de la version 17.2.
Les applications conformes à Posix peuvent être facilement conçues pour la reconnaissance de fichiers volumineux sans modification de la source : les nouveaux fichiers créés sur les disques fonctionnant avec les modules 17.2+ seront des fichiers de flux 64 bits (souvent appelés stream64) et sur les modules pré-17.2 seront des fichiers de flux ordinaires. Les applications qui utilisent l'interface VOS s$ ou les E/S en langage VOS sont appelées applications natives et celles qui utilisent des fichiers stream pourront accéder aux fichiers stream64 tant qu'elles n'utilisent pas d'opérations de positionnement d'octets (le positionnement sur BOF ou EOF n'est pas considéré comme un positionnement d'octets) OU si le fichier est inférieur à 2 Go.
- Applications autochtones existantes
De nombreuses applications natives doivent simplement modifier l'utilisation de la commande create_file (ou s$create_file) pour indiquer que l'organisation est STREAM64 plutôt que STREAM. Si l'application utilise des opérations de positionnement et que le fichier atteint > 2 Go, alors s$seq_position produira une erreur : pour prendre en charge des fichiers plus volumineux, les appels à s$seq_position doivent être modifiés en s$seq_position_x. Là encore, l'utilisation des interfaces _x n'interfère pas avec la capacité de l'application à référencer les fichiers de flux normaux existant sur les modules qui peuvent ne pas prendre en charge les interfaces _x, tant que les arguments de positionnement sont dans la plage prise en charge. Ainsi, le changement permet d'accéder à n'importe quel type de fichier de flux et ne coûte rien en termes d'interopérabilité.
Les applications existantes qui utilisent uniquement des interfaces qui ne communiquent pas la position des octets : s$seq_read, s$seq_write, s$seq_position BOF/EOF pourront traiter les fichiers stream64 sans modification. De nombreuses applications sont écrites pour traiter des fichiers ASCII, qu'ils soient séquentiels ou en flux, et n'ont donc pas besoin d'être modifiées pour traiter des fichiers en flux 64 bits, quelle que soit leur taille.
Les fichiers de flux 64 bits ne peuvent pas avoir d'index, et donc un fichier de flux indexé ne peut pas être converti en flux64. Les fichiers de flux indexés ne peuvent pas atteindre une taille supérieure à 2 Go en raison de restrictions dans la mise en œuvre de l'index existant.
- Compatibilité
Comme les fichiers de flux 64 bits offrent un certain nombre d'avantages, ils devraient être adoptés dans la mesure du possible, si un index n'est pas nécessaire.
Tant que le fichier ne dépasse pas 2 Go, il peut être copié ou déplacé vers des modules exécutant des versions antérieures de VOS, et y apparaîtra comme un fichier de flux normal. Vous pouvez même déplacer un disque contenant des fichiers stream64 vers un ancien VOS, à condition que les fichiers ne soient pas "restreints". Un fichier est restreint lorsqu'il a une taille > 2 Go ou lorsqu'il est faiblement alloué ; ces fichiers ne peuvent pas être ouverts si le disque qui les contient est déplacé vers un VOS antérieur à 17.2 (des outils sont disponibles pour identifier les fichiers restreints si vous prévoyez un tel déplacement). Toutefois, les applications exécutant des versions antérieures de VOS peuvent ouvrir, lire et écrire n'importe quel type de fichier stream64 sur le réseau ; toute défaillance qui se produit est la même que si l'application fonctionnait sous 17.2+ (par exemple, utilisation de s$seq_position pour le positionnement des octets lorsque le fichier dépasse 2 Go).
- Produits à source ouverte
La plupart des logiciels ouverts pris en charge par VOS ont été convertis pour prendre en compte les fichiers volumineux, par exemple ftp, sftp, samba, etc. Cela a certaines implications. Depuis la version 17.2, vous pouvez désormais envoyer par ftp un fichier de flux à VOS sans vous soucier de la taille du fichier, car le démon ftp créera un fichier stream64. ftp écrit tous les octets et le fichier résultant ne sera donc pas épars (voir la section suivante), même s'il est principalement constitué de zéros binaires. Le simple fait de copier le fichier transféré peut réduire considérablement l'espace disque qu'il occupe. Si vous envisagez d'ajouter un index au fichier ftp'ed, vous devez d'abord le convertir en un fichier de flux ordinaire (et bien sûr, il ne doit pas dépasser 2 Go de longueur).
Allocation de ressources
Les blocs qui contiennent tous les zéros binaires ne sont pas toujours alloués aux fichiers stream64 et ne nécessitent donc pas d'espace disque. La commande gnu "truncate" (dans >system>gnu_library>bin) peut être utilisée pour tronquer et étendre la taille d'un fichier stream. Dans la version 18.0, VOS fournit une commande similaire appelée reset_eof. Les données au-delà de EOF sont indéfinies, mais lorsque EOF est étendu, le contenu du fichier à partir du point de EOF actuel est toujours défini par des zéros binaires.
Considérons un fichier stream ordinaire et un fichier stream64 :
create_file stm -organization stream
create_file s64 -organization stream64
et supposons que chacun d'eux ait un contenu "abc". Nous souhaitons étendre les fichiers de manière à ce que chacun occupe 2 milliards d'octets :
bash
bash-4.2$ troncature -s 2000000000 s64
bash-4.2$ troncature -s 2000000000 stm
La première demande se termine immédiatement tandis que la deuxième prend plusieurs minutes. Les fichiers présentent une équivalence logique :
bash-4.2$ ls -l
total 244382
-rwxrwxrwx 1 personne personne personne 2000000000 Feb 25 14:08 s64
-rwxrwxrwx 1 personne personne personne 2000000000 Feb 25 14:11 stm
Cependant, le nombre de blocs de disque que chaque fichier occupe est très différent, comme le montre la commande VOS list :
liste
Fichiers : 2, Blocs : 488764
w 4 s64
w 488760 stm
Dans la version 18.0, les opérations équivalentes peuvent utiliser la commande VOS reset_eof :
reset_eof s64 2000000000
La commande VOS vous avertira si vous demandez d'étendre un fichier de flux ordinaire de plus de quelques milliers de blocs, car cette opération est très coûteuse
reset_eof stm 2000000000
L'extension de eof à 2000000000 ajoutera 488281 blocs au fichier. Voulez-vous étendre stm de 1999999996 octets ? (oui, non)
Voici le fichier de flux 64 bits après avoir été étendu. Il se compose de deux blocs de données seulement :
dump_file s64
Bloc numéro 1
000 6162630A 00000000 00000000 00000000 |abc........................
=
Bloc numéro 488282
=
Le vidage du fichier de flux ordinaire stm fera apparaître les 488282 blocs qui ont été attribués, la plupart des blocs contenant des zéros binaires.
dump_file stm
Bloc numéro 1
000 6162630A 00000000 00000000 00000000 |abc........................
=
Bloc numéro 2
=
Bloc numéro 3
…
Bloc numéro 488282
=
=
Néanmoins, compare_files et diff considèrent les fichiers comme équivalents, mais doivent lire tous les blocs du fichier de flux ordinaire, ce qui dans ce cas peut prendre quelques minutes :
ready;compare_files s64 stm
prêt 14:29:47
prêt 14:31:24 45.877 46
Conversion de fichiers
La commande convert_stream_file permet de convertir entre n'importe lequel des types de fichiers séquentiels et de flux (flux, flux 64 bits, séquentiel et séquentiel étendu) et de modifier les étendues. En général, la conversion consiste à copier le contenu du fichier et, de cette façon, est similaire à la création d'un fichier cible vide et à l'utilisation de copy_file avec l'option -truncate. convert_stream_file peut être utilisé pour modifier le fichier en place et présente l'avantage de s'assurer que le contenu existant peut être représenté dans le nouveau format demandé avant de tenter la conversion.
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 <<<<<
Ensuite :
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
Le fichier résultant est affiché comme étant restreint (64-bit/rstr) en raison de sa rareté. La commande copy_file produira également un fichier épars. La conversion d'un fichier stream64 en un fichier stream ordinaire entraînera l'instanciation de tous les blocs, de sorte que le fichier résultant peut être considérablement plus volumineux que l'original.
Dans un fichier stream64, il n'y a aucune garantie qu'un bloc qui se trouve contenir des zéros binaires sera attribué sur le disque ou non. Par exemple, si vous écrivez quelques zéros dans un bloc qui finit par contenir tous les zéros, le bloc reste attribué - ou si un programme écrit explicitement des données zéros en remplissant des blocs. Seuls les blocs qui ne sont jamais écrits restent non alloués ; copy_file et convert_stream_file n'écrivent jamais de blocs contenant tous les zéros binaires.
Caractéristiques physiques
- Étendue
La limite de croissance réelle de tout fichier VOS est déterminée par la taille de son étendue, il est donc important de comprendre ce qu'est une étendue. La carte des fichiers VOS contient les adresses de disque pour chaque bloc de 4k dans un fichier ; elle est limitée à 523792 entrées et donc tout fichier sans étendue est limité à 2145452032 (523792 * 4096) octets. Ce chiffre est légèrement inférieur à 2**31 et constitue donc la limite réelle de la croissance d'un fichier de flux ordinaire.
Une étendue est un groupe de N blocs contigus sur le disque, où N est la taille de l'étendue. Le plan de fichier d'un fichier attribué via les extents contient l'adresse du premier bloc de l'étendue et permet ainsi au plan de fichier de représenter un fichier sensiblement plus grand. Les étendues allouées dynamiquement permettent une taille d'étendue allant jusqu'à 256, ce qui permet d'obtenir un fichier contenant 512 Go (Remarque : les étendues allouées statiquement qui permettent une taille d'étendue supérieure à 256 sont dépréciées, sauf pour l'utilisation avec des fichiers de pagination ; ceux-ci présentent de nombreuses restrictions et des problèmes de performance qui les rendent alors inacceptables pour une utilisation générale).
Pour dépasser les 2 Go, un fichier stream64 doit avoir des étendues dont la valeur déterminera sa limite de croissance réelle. Par exemple,
create_file stm64 -organization steam64 -extent_size 32
créera un fichier qui peut atteindre 64 Go.
Dans la version 17.2, la taille par défaut de l'étendue des fichiers créés par Posix Runtime est de 8, ce qui permet une croissance jusqu'à 16 Go. Ces fichiers se développent en 8 blocs à la fois, et la taille minimale de tout fichier est donc de 8 blocs. Cette valeur par défaut peut être modifiée par un administrateur système pour chaque module, mais plus le potentiel de croissance est important, plus la taille minimale d'un fichier est élevée. Des étendues plus importantes peuvent être un problème pour les applications qui produisent beaucoup de très petits fichiers.
- Comment l'étendue affecte l'allocation des fonds
Normalement, les blocs qui ne sont jamais écrits ne sont pas attribués aux fichiers stream64 ; cependant, si un bloc d'une étendue est écrit, alors tous les blocs de cette étendue sont attribués, même si certains contiennent tous les zéros binaires.
Supposons qu'un fichier sans extension contenant la chaîne abc (stm1) soit converti en un fichier avec une extension de taille 8 (stm8) :
dump_file stm1
Bloc numéro 1
000 6162630A 00000000 00000000 00000000 |abc........................
=
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
Bloc numéro 1
000 6162630A 00000000 00000000 00000000 |abc........................
=
Bloc numéro 2
=
Bloc numéro 3
…
Bloc numéro 8
=
L'option -brief a été ajoutée à dump_file dans la version 18.0 et peut être utile lorsque vous ne voulez pas voir les blocs qui sont physiquement présents, mais qui représentent des blocs "vides" (potentiellement inexistants). L'utilisation de cette option avec le fichier DAE-8 est illustrée ci-dessous :
dump_file stm8 -brief
Bloc numéro 1
000 6162630A 00000000 00000000 00000000 |abc........................
=
Cela est également efficace pour masquer les blocs "vides" contenant tous les -1′s pour les fichiers relatifs ou fixes.
- Étendues flexibles
Des extensions flexibles ont été introduites dans la version 18.0, permettant à un petit fichier de croître d'un bloc à la fois ; à mesure que le fichier grandit, la valeur de l'extension change. C'est la valeur par défaut pour tous les fichiers créés par les applications Posix dans la version 18.0 et c'est ce que vous obtiendrez avec la commande create_file si vous n'indiquez pas une taille d'extension spécifique :
create_file flex -organization stream64 -extent_size
Les fichiers à extension flexible sont appelés fichiers flex ; seuls les fichiers stream64 peuvent avoir une extension flexible. La commande display_file_status indique la taille de l'extension d'un fichier flex comme "flex".
display_file_status flex
nom : %swsle#Raid4>flex
organisation des fichiers : fichier de flux (64 bits)
dernière modification à : 15-02-25 12:06:25 est
…
étendue dynamique : oui
taille de l'étendue : flex
Si la commande display_file_status est exécutée sur un module antérieur à 18.0, elle s'affiche :
taille de l'étendue : -1
Si un fichier flex est copié sur un disque d'un module 17.2, il a des extensions qui sont la valeur par défaut pour ce module. S'il est copié sur un module 17.1 ou antérieur, le résultat est un fichier de flux ordinaire.
Dans la version 17.2+, compare_files ne voit pas de différences de taille entre les fichiers de flux, et les fichiers apparaissent identiques quelle que soit leur taille. Par exemple, supposons que %swsle#m109_mas soit un sur un module fonctionnant sous la version 17.2 :
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
prêt 14:42:38 0.001 6
L'exécution de compare_files sur un module antérieur à 17.2 montrera cette différence :
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex ne correspond pas à B (%swsle#m109_mas>Stratus>flex).
- Certains attributs des deux fichiers ne correspondent pas :
taille de l'étendue -1 8
Les fichiers Flex peuvent contenir un peu moins de 512 Go, plus précisément 540 142 534 656 octets contre 549 235 720 192 avec le DAE-256, mais présentent l'avantage que les petits fichiers se développent un bloc à la fois, puis 8, puis 32, puis 256, par opposition à toujours 256 blocs à la fois.
Vous ne devez pas monter un disque contenant des fichiers flex sur un module antérieur à 18.0 ; il existe des outils qui vous permettent d'examiner facilement un disque pour détecter la présence de fichiers flex. Si vous le faites accidentellement, les fichiers ne seront pas visibles et ne seront pas accessibles. Ces fichiers ou tout répertoire les contenant ne peuvent pas être supprimés et resteront donc intacts si le disque est déplacé vers un module fonctionnant sous 18.0+. Toutefois, si vous récupérez sur un module antérieur à 18.0, tous les fichiers flex seront éliminés et l'espace récupéré.
Outils
- Localisation des fichiers de flux 64 bits sur un module
Lorsque vous devez déplacer un disque vers une ancienne version de VOS, vous devez localiser les fichiers qui sont incompatibles avec l'ancienne version. Une commande est disponible pour vous aider dans cette tâche :
locate_stream_files -formulaire
---------- locate_stream_files ---------
noms_répertoires :
-profondeur :
-type : 64-bit
-briefing : non
-long : non
-peut également être souple, épars ou volumineux (ce qui permet de localiser les fichiers de flux 64 bits ayant cette caractéristique spécifique), ou tous (ce qui permet de localiser tous les fichiers de flux).
En fonction de la profondeur, les répertoires subordonnés sont recherchés et si le fichier possède l'un des attributs (non spécifié par le type), les informations concernant la taille et l'étendue sont également affichées. Si aucun nom de répertoire n'est donné, alors tous les disques du module sont recherchés à partir de la racine. Par exemple :
locate_stream_files -type 64-bit
Vérification des répertoires sur le disque %swsle#raid0-1...
%swsle#raid0-1 :
smb_test.stm64 (FLEX/grand)
smb_test.stmb
Total de 2 fichiers de flux 64 bits.
Vérification des répertoires sur le disque %swsle#raid0-2...
%swsle#raid0-2 :
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/large)
Total de 3 fichiers de flux 64 bits.
Vérification des répertoires sur le disque %swsle#Raid4...
%swsle#Raid4>otto :
b3 (DAE-8)
grand (DAE-256/grand/petit)
…
- Comparaison des blocs
Dans les versions 17.2 et 18.0, de nouvelles options sont disponibles pour la commande compare_files, qui sont utiles pour les fichiers de flux. La comparaison bloc par bloc des types de fichiers structurés VOS n'est généralement pas utile car deux blocs de valeurs différentes représenteront souvent les mêmes enregistrements logiques. Par exemple, les données inutilisées dans les enregistrements d'un fichier relatif au-delà de leur longueur actuelle sont imprévisibles. En outre, les fichiers séquentiels contiennent des octets de remplissage non définis. Le contenu des blocs des fichiers séquentiels étendus est complètement différent si la taille des enregistrements est différente, bien qu'ils représentent les mêmes enregistrements logiques.
Cependant, les comparaisons de blocs peuvent parfois être utiles pour les fichiers fixes et les fichiers en continu. Le problème est que compare_files est orienté vers les enregistrements et conçu pour montrer les différences en termes de numéros d'enregistrement (ou numéros de ligne) qui peuvent être localisés à l'aide d'un éditeur. Cela a posé des problèmes pour les fichiers de flux binaires qui ne sont pas organisés en termes d'enregistrements. Comme la taille des enregistrements pour un fichier est limitée à 32767 octets, l'utilisation de s$seq_read dans un fichier de flux lorsqu'une séquence de plus de 32k octets se produit sans qu'un délimiteur d'enregistrement NL n'intervienne fournira les 32767 caractères suivants, et ne permettra pas de distinguer si l'octet suivant était un NL ou non. Cela rend le résultat d'une comparaison orientée vers les enregistrements ambiguë pour les fichiers de flux qui contiennent des valeurs binaires plutôt qu'une séquence de caractères séparés par le caractère NL.
Ce problème a été traité dans la version 17.2 ; compare_files détectera les cas où de faux succès ont pu se produire précédemment - en particulier lorsque 32767 caractères suivis d'un NL correspondent à 32767 caractères non suivis d'un NL. Si cela se produit, une erreur sera signalée indiquant que le fichier de flux contient des enregistrements > 32767. Si cela ne se produit jamais, alors les résultats orientés vers les enregistrements seront valables et fiables. Mais dans tous les cas, lorsque tout ce que vous voulez faire est de vous assurer que les fichiers sont identiques, la comparaison des blocs d'un fichier non structuré est beaucoup plus rapide que la méthode orientée enregistrement. Le problème des comparaisons de blocs est qu'en l'absence d'enregistrements pour servir de repères, la comparaison après la première divergence est souvent dénuée de sens.
Dans la version 17.2, l'option -compare_blocks a été ajoutée à la commande compare_files à cette fin. Cela permettra de détecter rapidement si des fichiers non structurés sont identiques d'un bloc à l'autre et d'identifier le bloc auquel ils diffèrent. Pour le cas rare où la différence est due à une superposition (certains octets étant modifiés par opposition à insérés ou supprimés) et que le reste des fichiers sont identiques, l'option -continue est également disponible. Cette option vous permet de voir l'étendue des blocs qui diffèrent dans le reste du fichier. Si un octet a été inséré par exemple (par opposition à superposé), alors tous les blocs restants seront différents ; c'est-à-dire que la resynchronisation telle qu'elle est effectuée avec les comparaisons d'enregistrements n'est pas possible avec les comparaisons de blocs. Mais dans le cas auquel il est fait allusion, cette information supplémentaire a permis de constater que la seule différence était quelques octets superposés dans quelques blocs, représentant peut-être quelque chose comme un horodatage.
A titre d'exemple de -compare_blocks avec -continue :
compare_files flex dae256 -compare_blocks -continue
A (%swsle#m111_mas>Stratus>Newman>flex) ne correspond pas à B (%swsle#m111_mas>Stratus>Newman>dae256).
- Les blocs de données de 2 à 24 diffèrent.
- Les blocs de données de 33 à 488 diffèrent.
- 272 blocs supplémentaires dans le fichier B.
- Comparaison des fichiers épars
La commande compare_files examine tous les blocs physiquement présents dans un fichier. Cela peut poser un problème dans les fichiers peu nombreux, car un bloc de zéros binaires peut apparaître comme un bloc attribué dans un fichier, mais ne pas être présent dans un autre. Les fichiers peuvent être logiquement identiques, mais pas bloc pour bloc. En fait, l'utilisation de copy_file éliminera les blocs de zéros binaires dans la cible, et s'il en existe, cela garantira que la source et la cible ne seront pas identiques bloc pour bloc.
C'est également un problème dans les fichiers de flux basés sur l'étendue car tous les blocs d'une étendue sont toujours instanciés même s'ils contiennent tous des zéros binaires. Cela signifie que les blocs d'un fichier d'étendue clairsemé peuvent avoir une apparence différente de celle des blocs d'un fichier identique non basé sur l'étendue, même s'ils représentent exactement les mêmes données. L'exécution de copy_file ne peut pas éliminer les blocs zéros dans un fichier d'étendue.
L'exemple d'utilisation de -continue ci-dessus concerne en fait deux dossiers identiques, sauf que l'un a des étendues DAE-256 et l'autre des étendues flexibles.
Ainsi, un fichier DAE-8 dont le contenu est "abc" contiendra un bloc avec "abc" suivi de 7 autres blocs contenant des zéros binaires. Un fichier non étendu (ou fichier flex) ne contiendra qu'un bloc avec "abc", et un fichier DAE-16 aura un bloc "abc" suivi de 15 blocs de zéros binaires.
En utilisant la commande compare_files avec -compare_blocks, tous ces fichiers seront affichés comme étant différents, même s'ils représentent tous les mêmes données. Dans la version 18.0, l'option -compare_all_blocks est disponible pour cette situation. Cela permet à copy_file d'instancier logiquement les blocs manquants dans les fichiers comparés, ce qui donne une véritable comparaison bloc par bloc, les différences dues à la dispersion étant éliminées. Les blocs manquants dans les fichiers stream64 sont considérés comme tous les zéros binaires alors que dans les fichiers fixes (ou tous les autres types de fichiers) sont considérés comme binaires -1′s (tous les FFFF).
Dans un fichier très peu dense, cela peut rendre la comparaison beaucoup plus lente qu'en utilisant les options -compare_blocks, mais tout de même beaucoup plus rapide qu'en utilisant la comparaison orientée par défaut vers les enregistrements. Elle n'est généralement nécessaire que pour comparer des blocs de fichiers ayant des étendues différentes, bien qu'il y ait d'autres cas, comme mentionné, où la dispersion peut être différente. Cela est également utile pour les fichiers fixes ayant des étendues différentes.
Entreprise