J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 2. Dernière modification le 18 juin 2017 à 02:41.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.