Est-il possible qu'un seul bit change pour que mon fichier me montre une lettre "Q" au lieu d'un "S"

Dans notre application, nous utilisons Hibernate et PostgreSQL pour stocker des données. Dans l'une de nos tables de base de données, nous avons une colonne discriminante qui dit par exemple "TIPPSPIEL". Il s'agit d'une chaîne fixe et ne peut être manipulée par aucun utilisateur.

Soudain, nous avons eu une entrée dans cette immense table où nous avions "TIPPQPIEL" au lieu de "TIPPSPIEL". Nous ne savons pas comment cela peut se produire.

Est-il possible que notre disque dur commute un bit, de sorte que notre lettre "S" n'est plus codée en "1010001" mais devient soudainement un "Q" sur le disque dur avec un bit commuté comme ceci: 1010011?

Je ne suis pas un expert en physique du disque dur, mais je suppose qu'un système d'exploitation ou un disque a des sommes de contrôle et d'autres choses pour s'assurer que cela ne peut pas se produire.

Est-il possible qu'un seul bit bascule pour que mon fichier me montre une lettre "Q" au lieu d'un "S"?

MISE À JOUR: Nous avons fait une analyse plus approfondie. Notre base de données esclave obtient ses enregistrements WAL du maître (fonctionnalité PostgreSQL). Peu importe: notre serveur esclave doit être synchronisé. Mais l'esclave n'était pas synchronisé sur cette ligne particulière. Nous avons pu voir que cela s'est produit il y a quelques jours sans aucune interaction d'un utilisateur sur cette entrée particulière. Donc ça DOIT être un peu en train de tourner. effrayant!

database postgresql hard-drive

— Janning
source

Je préfère supposer que cela vient d'une mémoire défectueuse. Avez-vous toujours le journal, lorsque cette colonne a été écrite?

— ott--

C'est peu probable mais possible, les bits en transit sont retournés avec un haut degré de régularité, voir 'bitsquatting'

— Sirch

C'est tellement rare que nous voyons une question vraiment intéressante sur ce site, alors merci tout d'abord.

Je pense que ce que vous voyez est en effet une erreur sur un seul bit, incroyable que vous puissiez le voir pour être honnête, mais vous avez raison de supposer que le deuxième bit le moins significatif a été commuté (en supposant que vous utilisez ASCII en tous cas).

En ce qui concerne les sommes de contrôle, etc., quand elles ont été écrites sur le disque, il est probable qu'elles auront été vérifiées comme correctes - je suis sûr que ce problème s'est développé par la suite via une simple erreur de fuite magnétique. Mais vous avez raison, des vérifications d'encodage ont été effectuées, cela varie selon le fabricant, mais il y a probablement une erreur quelque part disant "cela semble un peu étrange" - mais quelle option votre chaîne d'E / S a-t-elle disponible? vous refuser tout le bloc? Je vais supposer qu'il s'agit d'un seul disque non RAID car ils ont tendance à avoir plus d'options sur les disques RAID lorsqu'ils détectent des erreurs.

C'est étrange, bien que ce genre de chose se produise probablement plusieurs fois par seconde à travers le monde.

— Chopper3
source

Vous avez raison, il s'agissait dans ce cas d'une configuration de disque non Raid. comme mon analyse plus approfondie montre que cela s'est produit bien après la rédaction du dossier.

— Janning

Si mes 20 ans en tant que sysadmin, j'ai vu 3 cas d'un seul bit-flip. Un seul d'entre eux a pu être prouvé à 100%. Les 2 autres étaient soupçonnés d'être des mèches retournées, nous ne pouvions pas en être sûrs. (Bit aurait pu basculer dans la mémoire après avoir lu le fichier. Au moment où nous avons remarqué la différence, le fichier d'origine n'était plus disponible ou avait été touché. Je suis sûr que cela se produit plus souvent que tout le monde ne le pense, mais il est rarement remarqué et généralement pas prouvable s'il est remarqué.

— Tonny

Le fait de ne pas lire le bloc entier est exactement ce que font les lecteurs lorsqu'ils obtiennent une erreur non corrigible. Il est impossible d'avoir un seul flip bit dans la partie données utilisateur du secteur et de ne pas être détecté. Le bit doit avoir été retourné lors de son écriture sur le disque.

— psusi

Faut-il rendre cette question canonique?

— Deer Hunter

@psusi Pas impossible, car vous avez juste besoin de suffisamment de bit-flips dans le secteur pour que l'ECC sorte bien. Peu probable, mais possible, et les fabricants de disques citent des taux d'erreur suffisamment élevés que vous devriez vraiment vous attendre à en voir. J'ai entendu des rumeurs selon lesquelles les gens de ZFS les verraient (en raison des sommes de contrôle des données de niveau ZFS) ...

— derobert