[résolu] raid5, fichiers corrompus & compagnie

Bonjour à tous.

J’ai posté il y a quelques jours pour un problème de raid mais je n’ai malheureusement pas trouvé echo. Voir http://forum.debian-fr.org/viewtopic.php?t=4578.

Vu que j’avais eu des soucis au moment de créer le raid5 sur l’ancienne config, hier, j’ai détruit les partitions via fdisk et j’ai recommencé la procédure. Cette fois-ci, j’ai installé tout le bordel sur un ordinateur plus puissant histoire de ne pas perdre mon temps.

Je reviens donc à la charge avec deux autres problèmes mais que j’avais déjà avant.

Voilà la config du PC:
Athlon XP 1600+
1Go de ram
3x250Go de disques durs
Debian Etch 2.6.17.11 (de nouveau compilé avec le changement d’ordinateur)

Organisation des partitions/disques:
md0: /boot RAID1 (70mo), 2 disques actifs, 1 spare
md1: / RAID1 (20Go), 2 disques actifs, 1 spare
md2: tout le reste en RAID5 et donc 3 disques actifs.
Le système de fichiers est ext3.

Les deux premiers disques occupent les ports de la carte mère tandis que le 3ème est sur une carte controlleur Promise PDC20262 IDE UDMA66.

Je fais du raid logiciel avec mdadm.

Pour remplir md2, j’ai branché des disques durs (avec le backup de mes données) sur le port libre de la carte controlleur et je les ai copiées. J’ai également procédé à la copie via FTP en réseau local.
Bref, j’ai copié plus de 200Go de données pour un espace total de 423Go.
Seulement j’ai le même problème que j’avais déjà avec la configuration matériel précédente (cf le lien).

Les problèmes:

  • Le 1er:
    Certaines données sont corrompues mais pas toutes.
    Les symptômes: des vidéos sont indiquées comme endommagées par VLC et ce dernier se propose de les réparer avant de les lire. Ces mêmes vidéos n’ont plus la bonne durée (72h au lieu de 45 min par exemple), il y a des pertes de signal, c’est à dire que la couleur s’étale et il y a également les pertes de l’audio caractérisées par un petit bruit aigüe qui rappelle les problèmes de freeze de certaines freebox au lancement de la TV.

  • Le deuxième:
    Quand j’essaye d’accéder à des données, j’ai droit à un joli message qui traverse l’écran “md2: rw=0, want=18463474688, limit=901021184 attempt to access beyond end of device”.

Avec l’ancienne configuration matérielle, j’étais confronté à la limite de reconnaissance de la taille des disques durs par le BIOS à 137Go. Une fois booté sous linux, ils étaient correctement reconnus à 250Go chacun, ce qui est normal. Mais puisque j’avais ce problème, je tâchais de trouver une raison. Je pensais donc que cette limite d’atteinte des données à 137Go pouvait malgré tout être une conséquence de ce problème de “beyond end of device”. Or, cette hypothèse tombe à l’eau puisque cette fois-ci, je suis quand même avec un ordinateur plus ou moins récent, un XP 1600+. J’en reviens donc à une autre hypothèse, ma carte contrôleur mettrait-elle la zizanie ?

Plus haut, je parlais de problème lors de la création de mon raid5 sur l’ancienne configuration. Vu que les ports de la carte mère (celle où le processeur est un K6-2 400Mhz) sont en UDMA33, j’avais mis une nappe 40 broches sur la carte contrôleur. Ainsi, les 3 disques sont à la même vitesse et je ne “gâche” pas une nappe 80 broches. Or, sous linux, j’ai eu des problèmes de DMA et j’ai cherché un bon moment avant de découvrir qu’il fallait soit désactiver le DMA (ce que je ne voulais pas) soit mettre une 80 broches. La deuxième solution a été la bonne et j’en ai été étonné.

Je n’ai aucun problème quant à mon RAID1, les données ne sont absolument pas corrompues, tout va bien. Sauf que le disque branché sur la carte contrôleur est en spare pour le RAID1 donc de ce côté là, il ne bosse pas.

Je suspecte donc fortement cette carte contrôleur. Cependant quand je branche des disques durs dessus, je n’ai aucun problème. C’est uniquement pour le raid 5 que ca pose problème.

Du côté de mdadm, tout est clean sur le raid ou les durs.

Voilà j’espère avoir été assez complet pour que vous puissiez cerner au mieux le problème. Si vous pouviez me donner des idées, des conseils et autres suggestions pour faire avancer le schmilblik parce que je commence à être à cours d’idées.

Merci.

Dest.

Je n’ai pas répondu à ton post précèdent parceque je n’avais rien d’interressant à dire.
En cherchant à me remêmorer le RAID5 sur wikipedia, je suis tombé là dessus:

[quote]On a trop souvent tendance à croire qu’un système RAID 5 est totalement fiable. Il est en effet généralement admis que la probabilité de défaillance de plusieurs disques est extrêmement faible. (On parle évidemment d’une défaillance entraînant la perte de données définitive sur plusieurs disques et non d’une simple indisponibilité de plusieurs disques). Cela est vrai pour une défaillance générale d’une unité de disque. Cependant, cela est totalement faux si l’on considère comme “défaillance” un secteur illisible.

En effet, dans la pratique, il est très rare que toutes les données d’un volume soient lues régulièrement. Et quand bien même ce serait le cas, la cohérence de la parité n’est que très rarement vérifiée pour des raisons de performances. Il est donc très probable que des défauts tels que les secteurs illisibles ne soient pas détectés pendant une très longue période. Lorsque l’un des disques devient réellement défectueux, la reconstruction nécessite de parcourir l’intégralité des disques restants. On peut alors tomber sur des défauts qui étaient restés invisibles jusque là.

Tout ceci pourrait ne pas être bien grave et occasionner la perte d’une quantité de données minime. Cependant, l’extrême majorité des controleurs raid est incapable de gérer les “défaillances partielles”. Ils considèrent généralement qu’un disque contenant un secteur illisible est totalement défaillant. A ce moment là, 2 disques sont considérés défaillants simultanément et le volume RAID 5 devient inutilisable. Il est alors extrêmement difficile de récupérer les données.

Un système RAID 5 doit donc absolument être vérifié et sauvegardé très periodiquement pour s’assurer que l’on ne risque pas de tomber sur ce genre de cas.[/quote] En gros, si tu as des secteurs foireux, ça ne gène pas trop le fonctionnement du RAID mais tes données sont quand même pourries.
Je vais te relire, pour voir mieux ce que tu cherches.

Il y a un truc que je ne comprends pas:
3 disques de 250. Sur chacun, tu réserves 90 pour md0 et md1, ça veut dire qu’il te reste 3 fois 160. Donc en RAID5, ça doit faire 320 Go, et pas 423 ?

pour md0 et md1, je réserve 0.073 + 203 = 60.21Go.

Sur un disque de 250Go, il y a environ 233Go utilisable (de mémoire).

Donc 233*3 - 60.21Go = 638.79Go.

Ce qui me fait 638Go d’espace restant en tout.

Seulement il ne faut pas oublier qu’avec le raid5, on perd un disque dur pour la parité. Dans mon cas je perds 1/3 de capacité.

638.79*2/3 = 425Go environ. On retombe donc sur nos pieds.

Ca c’était pour le côté mathématiques du raid5.

Ensuite, pour te répondre, j’avais effectivement pensé aux secteurs pourris mais vu que tout était formaté, j’avais la flème. Il est vrai que malgré que les durs soient neufs, ca n’exclue pas les secteurs défectueux.

Hier soir, j’ai mis en faulty puis j’ai remove du raid le disque dur branché sur la carte controlleur. J’ai ensuite balancé un tas de données via le réseau local. Ce qui veut dire que ces données ont été écrites sur 2 disques sur 3 et ne devrait pas avoir été corrompue par la carte. C’est un moyen comme un autre de vérifié une hypothèse. Je n’ai pas encore vérifié l’intégrité des données, je le ferai tout à l’heure, je retourne me coucher :smiley:

Aux temps pour moi: j’avais compté 70Go pour md0.
Ce qui fait bien trois disques de (233 - 20.07) ~= 213Go par disques, soient 426 Go de RAID5. On les retrouve…
Désolé.

Bon, j’ai fait mes tests et je peux rendre un verdict sur l’état des données.

Je rappelle qu’hier soir, j’avais retiré du raid le disque dur branché sur la carte controleur IDE. J’ai ensuite balancé 120Go sur le réseau histoire de le remplir un peu.

Verdict: les données ne sont pas corrompues.

Là où je suis étonné c’est que les données déjà présentes ne sont plus corrompues.
Pourtant il y a une partie des données que j’ai copiées de disque dur à disque dur et le disque source était branché sur la carte controleur.

Alors, ce serait la carte contrôleur ou le disque sur la carte contrôleur qui serait défectueux ?
Cela fait près d’un an que j’ai ce disque et je ne m’en suis jamais plaint. De plus, avant de le mettre dans le raid5, je l’avais formatté bas niveau et il a même herbergé linux un moment sans problème.

Qu’est-ce que vous me conseillez ? Est-ce que je dois raquer dans une nouvelle carte contrôleur ? Comment faut-il procéder pour détecter les secteurs défectueux avec les outils de linux ? Le disque est un Maxtor et quand je l’avais formaté bas niveau, il avait passé avec succès les étapes de tests.
Un ami me dit que s’il s’agissait de secteurs défectueux, j’aurais eu une tonne d’erreurs lors de l’écriture.

lis les rapports de bug de mdadm

J’ai finallement craqué et j’ai été acheté hier une nouvelle carte controleur. La mienne était un peu vieille, celle-ci est neuve et j’ai le support de l’ATA 133 en prime.

Une carte avec un chipset Silicon Image qui fonctionne très bien avec ce qui est fourni dans le noyau.

J’ai branché mes 2 deux durs en raid 1 sur cette carte tandis que le dernier dur est sur les ports de la carte mère. De ce fait, je bénéficie de l’ATA 133 pour le système.

Je n’ai plus de problème de données corrompues et je n’ai plus le problème de “access data beyond the disk”, ce qui confirme une bonne fois pour toutes que c’était ma carte controleur qui merdait.

C’est bizarre quand même. Elle marchait bien jusqu’à maintenant.

Il faut bien que ça meure un jour.

plutot le driver de la carte ou mdadm qui deconnais avec a mon avis… ca ne meure pas comme ca le matos info en gle.

C’est possible que mdadm puisse merder avec une carte ? Parce que justement à mon goût, la carte fonctionnait bien et ca a merdé à partir du moment où je voulais faire du raid.