Cette réponse est une combinaison de celle de @ lechlukasz et @ db48x , incorporant également certains points soulevés dans les commentaires ainsi que certaines de mes propres pensées.
Le chemin simple à suivre est une approche combinée de système de fichiers et de métadonnées distinctes.
En utilisant un système de fichiers qui effectue le hachage et la validation des données à la volée, comme ZFS ou Btrfs (notez que bien que de grandes avancées aient été faites, Btrfs n'est pas considéré comme prêt pour une utilisation en production pour le moment), vous pouvez être raisonnablement assurez-vous que si les données peuvent être lues sur le disque sans que le système d'exploitation ne fasse d'erreur, alors les données lues ont été écrites sur le disque de la manière prévue par le système de fichiers. En exécutant des opérations de "nettoyage" périodiques, toutes les données sont lues et vérifiées par rapport à l'idée du système de fichiers de ce qu'elles devraient être.
Cependant, cela ne protège que contre la corruption sur le disque (blocs illisibles, erreurs d'écriture matérielle pure et simple, écritures non valides qui corrompent des parties des données directement sur le périphérique de bloc, etc.). Il ne protège pas contre un bogue logiciel, une opération incorrecte de l'utilisateur ou un logiciel malveillant qui fonctionne via les installations du système d'exploitation prévues pour travailler avec des fichiers, en supposant que ces installations sont exemptes de ces bogues.
Pour vous protéger contre ces derniers, vous avez besoin d'une autre couche de protection. Le contrôle de somme ou le hachage des données du point de vue d'une application utilisateur aidera à protéger contre de nombreux risques mentionnés ci-dessus, mais doit être effectué séparément (soit en tant qu'action de processus intégrée dans le logiciel, soit en tant que processus complètement distinct).
Avec le matériel d'aujourd'hui et ce qui est pratique pour stocker de grandes quantités de données (disques durs à plateau tournant par opposition aux disques SSD / SSD), même les algorithmes de hachage complexes tels que SHA1 seront largement liés aux E / S - c'est-à-dire la vitesse à laquelle les données sont hachées sera fonction de la vitesse de lecture du système de stockage, plutôt que de la capacité du processeur de l'ordinateur à calculer le hachage. J'ai fait une expérience avec l'exécution d'un processus de hachage MD5 dans l'espace utilisateur sur environ 150 Go de données sur ce qui était en 2012 un PC grand public, et il s'est terminé après avoir exercé le disque essentiellement sans interruption pendant environ 40 minutes. En multipliant par 100 ces chiffres, vous obtiendrez les hachages MD5 d'une collection de 15 To en environ trois jours sur ce même matériel. En ajoutant le taux de transfert de lecture (qui peut être facilement réalisé, par exempleRAID 0, par exemple, est un striping sans redondance, couramment utilisé pour obtenir des performances de lecture / écriture plus élevées, éventuellement en combinaison avec RAID 1 formant RAID 10 ), le temps jusqu'à la fin peut être réduit pour la même quantité de données.
En combinant les deux, vous obtenez le meilleur des deux mondes: le système de fichiers vous donne l'assurance que ce que vous avez reçu lors de la lecture du fichier est ce qui a été réellement écrit, et un processus de vérification de la fixité distinct peut s'exécuter sur l'ensemble de la collection, garantissant que les données stocké correspond toujours à ce qui a été ingéré dans l'archive. Toute incohérence entre les deux (le système de fichiers dit que le fichier est OK, la vérification de la fixité dit que ce n'est pas le cas) indiquera un fichier qui a été modifié en dehors du mode de fonctionnement prévu de l'archive mais à partir des installations du système d'exploitation, provoquant une restauration à partir d'un secondaire copie (sauvegarde). Le contrôle de fixité peut ainsi s'exécuter à un intervalle de temps plus long, ce qui devient essentiel pour les très grandes archives, mais tous les accès en ligne sont toujours garantis de ne pas être corrompus sur le matériel si les lectures réussissent. En principe, le logiciel d'archivage pourrait s'appuyer sur le système de fichiers pour signaler les incohérences en tant qu'erreurs de lecture et effectuer une vérification de la fixité distincte en arrière-plan pendant que l'utilisateur travaille avec le fichier et affiche un message approprié si cela indique que le fichier ne correspond pas à ce qui a été ingéré dans l'archive. En utilisant un système de fichiers de hachage de blocs, un tel schéma aurait un impact minimal sur les performances perçues tout en garantissant que le contenu est correct.