Comment by OVH - Friday, 19 June 2009, 11:51AM

Jun 19 11:35:59 filerz27 savecore: [ID 570001 auth.error] reboot after panic: ZFS: bad checksum (read on <unknown> off 0: zio fffffe8260be7300 [L0 zvol object] 2000L/2000P DVA[0]=<4:3a1de6000:2000> fletcher2 uncompressed LE contiguous birth=3890041 fill=1 cksum=bca0754d264f625

On remonte les volumes.

Comment by OVH - Friday, 19 June 2009, 15:12PM

Le filer a remonté puis a replanté.

Nous avons coupé le proxy iSCSI qui l'a fait planté.

Le filer est à nouveau up. Les file systeme de 3 RPS sont à l'origine
de la panne. Nous les desactivons. Le redemarrage de l'iSCSI. Tous les
RPS (-3) sont UP à nouveau.

On a essayé de faire le rollback de backup local. Pareil, les 3 RPS
sont en erreur. Nous les deplacons. Et on copie les données du backup
effectué ce matin.

Comment by OVH - Friday, 19 June 2009, 15:24PM

le 1er est en cours. le backup fait ce matin.
zfs send filerbackup12/filerz27_r15792@2009-06-19 | zfs receive filerz27/r15792

Comment by OVH - Friday, 19 June 2009, 15:32PM

pour les 2 suivants c'est le backup d'hier (celui d'aujourd'hui était seulement en cours)
zfs send filerbackup12/filerz27_r24803@2009-06-18 | zfs receive filerz27/r24803
zfs send filerbackup12/filerz27_r23986@2009-06-18 | zfs receive filerz27/r23986

Comment by OVH - Saturday, 20 June 2009, 10:52AM

Le filer a replanté ce matin. Nous sommes en train de le remplacer par un spare.

Comment by OVH - Saturday, 20 June 2009, 13:25PM

Le changement par le spare a été effectué. Le filer est en train de remonter tous les volumes.

Comment by OVH - Saturday, 20 June 2009, 15:01PM

Le serveur iscsi a été relancé. Apparemment 18 volumes sont affectés par la même panne.
Nous lançons un process de verification sur tout le pool de donnée pour vérifier qu'il n'y a pas d'autres éléments affectés.

L'origine de la panne semble être une barette de ram défaillante qui a dû générer des corruption au niveau des checksum de zfs.
Le changement par un spare a résolu ce problème.

Comment by OVH - Sunday, 21 June 2009, 00:59AM

scrub: scrub completed with 138 errors on Sun Jun 21 00:48:17 2009
Les 138 errors sont situées parmi 24 volumes rps. Nous sommes en train de les rappatrier depuis le backup
pour les remettre en prod sur une autre infrastructure.

Par ailleurs, plusieurs erreurs se sont retrouvés dans les metadata du système de stockage des volumes.
Ceci va nous obliger à basculer tous les volumes présents sur le filer, toujours fonctionnels, sur une
nouvelle infrastructure dans la semaine.