Pour ceux qui n'en ont jamais entendu parler, il s'agit d'un projet ayant pour but de définir et mettre en œuvre un format de fichier servant de correcteur d'erreur à un ensemble de fichiers lors de son échange. L'utilisation principale et la plus connue est le transfert de fichier par l'intermédiaire des newsgroups (alt.binaries.*).
L'ensemble des travaux sur une éventuelle norme sont disponibles sur la liste de diffusion parchive-devel. La première version des spécifications date de juillet 2001 ; le principe consiste à utiliser le code Reed-Solomon (RS) pour adjoindre à un ensemble de fichier des données supplémentaires qui permettront de reconstruire l'ensemble original en cas d'endommagement. Le code RS est également utilisé dans les CD, les DVD, la transmission par satellite ou par ADSL.
La deuxième version a vu le jour en janvier 2002 afin de combler quelques lacunes : travail sur des blocs de données plutôt que sur les fichiers eux-mêmes pour ne pas être dépendant de la taille des fichiers ni de leur nombre, utilisation de nombres sur 16 bits plutôt que sur 8 bits, correction d'une erreur dans l'algorithme (2003) due à une erreur dans la publication de James Plank (1997).
En août 2008, un membre du comité suisse de l'ISO agissant à titre personnel a proposé aux membres du projet d'utiliser le processus « Fast-Track » pour soumettre le format Parchive à l'ISO et en faire une norme. Il proposait de réécrire les spécifications en suivant les normes ISO/IEC, mais avait besoin de l'accord des détenteurs du droit d'auteur. L'idée de proposer PAR2 comme norme lui est venue car il a trouvé que les spécifications étaient matures, que les implémentations étaient suffisamment vieilles et qu'il n'y avait pas de danger de brevets sur l'aspect mathématique car le code RS est assez vieux.
S'en est suivi une discussion sur la liste de diffusion sur de nombreux points techniques afin d'éclairer les zones floues de la spécifications aussi bien mathématiques que techniques. En novembre 2008, un bug est trouvé dans l'implémentation du code Reed-Solomon qui fait que parchive est un code Maximum Distance Separable (MDS), pour certain cas (exceptionnels) il n'a plus sa fameuse propriété : il suffit de N blocs pour récupérer N erreurs. À partir de là, il n'est plus question de proposer ce format à l'ISO.
Les membres du projet décident de repartir sur des bases propres pour faire le format PAR3. L'idée est de découper le format en plusieurs parties pour le proposer à l'ISO : une partie générique qui décrira le format et les en-têtes, puis un partie pour chaque code correcteur pris en charge. En effet, le projet se dirige également vers l'utilisation de codes Low Density Parity Codes (LDPC) qui nécessitent N+C blocs pour récupérer N erreurs mais qui sont beaucoup plus rapides.
Début janvier 2009, un mécène décide de subventionner le travail sur la spécification PAR3, ce qui a conduit à la rédaction des cas d'utilisations du futur format.
Aller plus loin
- Site officiel (20 clics)
- Liste de diffusion parchive-devel (5 clics)
# Mais que fait Albanel?
Posté par Maclag . Évalué à 10.
La FRANCE ne peut laisser passer ça et s'opposera bien sûr sur des considérations purement techniques à la standardisation de cet outil pour déviants de l'Internet.
[^] # Re: Mais que fait Albanel?
Posté par ioctl . Évalué à 10.
[^] # Re: Mais que fait Albanel?
Posté par Janfi . Évalué à 8.
# Pas que ça...
Posté par Hugues Naulet . Évalué à 2.
Je l'ai rencontré en entreprise pour le stockage massif de données sensibles sur des supports qui le sont tout autant (cd-r, bandes magnétiques).
# Gérer des troues de 4Ko
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, il avait trouver des flip de 1 2 ou 3 bits consécutifs et des bloc complets de 4Ko de zéro sans doute dû à des erreurs de paginations d'OS.
L'idée était d'utiliser une correction d'erreur mais entrelacé. D'habitude, on travaille avec 32 bits pour rajouter 4 bits d'ECC pour corriger 1 erreurs et en détecter 1 ou 2 en plus, voir des bloc de 64 bits avec 4 bits en code RS pour corriger un blocs complet fautif (utilisé dans le spatial).
Détecter et corriger 4Ko consécutif d'erreur est un peu monstrueux d'où l'idée d'entrelacer un grand nombre de mots. Si on utilise un algo RS sur 64+4 bits. On a des bits de 0 à 68. Ensuite on a le mot suivant A puis B... Habituellement, on travaille sur A0-A64 puis B0-B64 pour trouver A64-A68 et B64-B68. Dans l'idée de bloc, on décompose le paquet d'origine comme A0-B0-C0 ... jusqu'à A64-B64-C64. Si on entrelace 32000 mots ainsi, même avec un perte de 32 000 bits consécutifs, on peut retrouver tous les bits perdus.
Il y a un autre avantage, c'est que tous les calculs sur des mots de 128 bits sont indépendant et que l'on peut utiliser les opérations binaires SSE en 128 pour accélérer les calculs.
Je ne sais pas si PAR fonctionne comme cela, mais si il permet de retrouver des troues de 4Ko, c'est un très bon candidat pour la conservation à long terme.
"La première sécurité est la liberté"
[^] # Re: Gérer des troues de 4Ko
Posté par Beretta_Vexee . Évalué à 2.
Qu'un bloc soit totalement absent ou n'ait qu'un bit de corrompue, il faudra de toute façons un bloc de parité de taille équivalente pour le régénérer. Le reed salomon est vraiment bluffant pour cela.
LDPC quand a lui fonctionne via une fenêtre glissante et non par bloc, il est donc potentiellement plus adaptés aux problèmes de flux, car il peut réparer des erreurs répartie sur l'ensemble des donnés. Ce qui est un cas assez rare pour le stockage et le transfert des fichiers.
[^] # Re: Gérer des troues de 4Ko
Posté par Beretta_Vexee . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: quickpar
Posté par wismerhill . Évalué à 3.
Parce que, pour mon usage personnel, les commandes par2(create|verify|repair) sont tout à fait satisfaisante.
Bien sur pour un utilisateur de base ce serait mieux avec une interface graphique, mais si c'est le seul avantage de quickpar c'est bien faible.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: quickpar
Posté par Beretta_Vexee . Évalué à 2.
Il se fiche des noms de fichiers ou de la répartition des donnés dans les différents fichiers, ce qui est très utile en cas de problèmes de charset, de nom, de traitement partiel, etc.
Il recolle les fichiers splités.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.