Comme la question ci-dessus, est-ce que 7zip (plus précisément p7zip sous Linux) utilise de l'espace disque pendant le test des archives ? Comme je n'ai qu'un disque de 2 To pour travailler et que la taille de chaque archive varie entre 800 Go et 1 To, je pensais tester deux archives en même temps plutôt qu'une seule.
La documentation officielle de 7zip ne mentionne pas l'utilisation du disque lors des tests.
Ça ne devrait pas. (Mais ça pourrait)
Afin de vérifier que les données d'une archive sont correctes au moment de l'extraction, un CRC ou code de détection d'erreur est associé à chaque fichier ou bloc de données.
Lors de la décompression d'un fichier, il est très utile, d'un point de vue d'efficacité, d'effectuer la vérification des erreurs. avant écrire des données sur le disque. Sinon, vous gaspillez de précieuses ressources en lisant les archives, en les écrivant sur le disque, puis en relisant les données sur le disque pour vérifier les erreurs. Avec une archive volumineuse ou sur un système à mémoire limitée, cela pourrait doubler le temps de décompression d'un fichier, ce qui serait inacceptable. Je suppose que dans ce cas, la lecture et l'écriture sur le disque sont les parties les plus lentes du processus.
Si vous effectuez la vérification avant l'écriture, vous pouvez effectivement faire passer l'archive par le décompresseur, par votre algorithme de vérification des erreurs, puis par le disque, en supposant que le sous-système du disque sait ce qu'il fait. Le travail est terminé.
En procédant de cette manière, "tester" l'archive devient une opération gratuite. Vous suivez exactement les mêmes étapes que pour la décompression, mais vous jetez simplement les données sans les écrire sur le disque.
J'espère fortement que c'est ainsi que cela fonctionne, car écrire tout sur le disque simplement pour tester une archive semble insensé et ne serait pas plus rapide qu'une "vraie" décompression des données. Le fait que le "test" soit plus rapide implique qu'au moins une étape, très probablement l'écriture des données sur le disque, est sautée.
Non, ce n'est pas le cas - du moins pas la version 19.00.
Tester plusieurs fichiers en parallèle fonctionne très bien sur les disques durs solides, mais tue généralement les performances sur les disques mécaniques - beaucoup de recherche est alors nécessaire pour lire plusieurs archives en parallèle. Ainsi, la recommandation suivante peut être faite :
Lorsque vous testez des archives sur des disques durs solides (NVMe ou SATA SSD), lancez autant de processus que vous avez de cœurs (si vous le pouvez).
Lorsque vous testez des archives sur le même lecteur mécanique (ou volume RAID mécanique), lancez un, ou au maximum deux processus.
Lorsque vous testez des archives sur des clés USB, les résultats varient.
La triste majorité des "clés USB" ou "sticks" courants sont d'une lenteur abyssale, même en lecture, c'est-à-dire loin de saturer la bande passante de l'interface USB. Certains de ces disques deviennent encore plus lents lorsqu'ils accèdent à des données provenant de plusieurs zones disparates du disque en même temps. Cela est dû à la RAM limitée du contrôleur de disque. Le contrôleur n'est pas en mesure d'intégrer toutes les métadonnées nécessaires pour accéder à la totalité du disque en une seule fois dans la RAM, et finira par relire les métadonnées du support flash lorsqu'il changera de zone de lecture sur le disque, devant souvent suivre des chaînes de liens pour les trouver. Ces lectures de métadonnées ne sont souvent pas parallélisées par le lecteur, même si la disposition de la mémoire flash le permettait, et sont souvent mises en œuvre en utilisant des chemins de code dédiés qui sont tout simplement lents.
Le seul moyen sûr d'y remédier est de faire un test de bande passante. Supposons que vous deviez vérifier les archives a , b , c , d , e y f qui sont toutes du même ordre de grandeur en termes de taille. Il faut les trier par ordre décroissant de taille. D'abord, chronométrer la vérification de a et calculer la largeur de bande BW_a = time_a / size_a . Ensuite, faites la vérification de b y c en parallèle, et calculer ces largeurs de bande. Tant que leur somme sum_BW_bc est plus grande que BW_a vous gagnez en performance. Vérifiez alors d , e y f en parallèle et calculer ces largeurs de bande. Tant que leur somme sum_BW_def est plus grande que sum_BW_bc vous gagnez en performance. Et ainsi de suite. Vous finirez par atteindre le nombre de flux pour lequel la bande passante totale diminue par rapport au test précédent. Continuez à vérifier les archives restantes en utilisant le nombre de flux précédent, plus petit.
Cette méthode peut être appliquée à n'importe quel disque, bien que la baisse de performance avec les disques mécaniques soit si importante qu'elle peut affecter indûment la performance globale de votre processus de vérification. Pour cette raison, les tests parallèles doivent être terminés lorsqu'on sait que leur bande passante est inférieure à 90% de la bande passante de l'étape précédente. Pour ce faire, vous pouvez recalculer la largeur de bande à chaque seconde d'exécution du test et mettre fin au test lorsque la largeur de bande est inférieure au point de coupure.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
