Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 03/04/2013, à 18:47

zapan999

ext4 hs après un grow mdadm puis resize2fs

Bonjour,

Après quelques année d'utilisation de mdadm, je n'avais jamais eut de problèmes insurmontables... mais voilà, il y a un temps pour tout!

Je vous explique:

après avoir rajouter un disque de 3To à ma grappe raid5 sous mdadm (passage de 6 disks +1 spare à 7 disk +1 spare), j'ai fait le grow de ce raid sans aucuns problèmes.

après 14 heures de growing, le raid était ok, filesystem ok, enfin tout était parfait.

j'ai donc lancer le resize2fs, mais au bout d'un certain temps, plantage du serveur (powerloss hmm)

redémarrage, et là, c'est le drame...
fsck se lance au démarrage, et j'obtiens des milliers de lignes
"Erreur de lecture du bloc 1xxxxxxxxx (La tentative de lecture d'un bloc depuis le système de fichiers a produit une lecture tronquée) lors de l'obtention de l'i-noeud suivant depuis l’examen, ignorer l'erreur ?" en réponse automatique "oui"
l'erreur de lecture du bloc pourrais-elle venir du fait que cette partition ext4 fait maintenant 18To (erreur d'adressage?)

après de longues minutes, je me retrouve avec un volume bien monté, mais avec seulement les trois ou quatre fichiers présents à la racines, et plus aucuns répertoires, soit une perte de plus de 13To de données...


si vous avez besoin de plus d'informations, ou si quelqu'un a une piste, voir une bonne idée...


Cordialement,
zapan999

Hors ligne

#2 Le 03/04/2013, à 22:12

zapan999

Re : ext4 hs après un grow mdadm puis resize2fs

Bon petite mise à jour:

une partie du probleme vient du fait que mon ubuntu 32 bits ne pouvais pas supporter une tel taille avec des block de 4k...

install d'un ubuntu en x64 et hop, un coup de e2fsck et j'ai récupérer... 17% de donnée, dans lost and found... autant dire je suis pas sortit d'affaire encore.... je vais tenter de titiller les superblocks de backup, mais si quelqu'un à des idées... je suis toujours preneur.

Cordialement,

Zapan999

Hors ligne

#3 Le 03/04/2013, à 23:23

jamesbad000

Re : ext4 hs après un grow mdadm puis resize2fs

Bonsoir,

Les superblock de secours ne sont que des copies du 1er superblock, et ne contiennent que des caractéristiques générales du système de fichier... Il ne servent qu'en qu'a d'écrasement du 1er superblock et ont du être resynchronisés suite un fsck abouti.

Le meilleurs espoir qu'il te reste selon moi, c'est utiliser photorec pour scanner les emplacement non alloués de ta partitions et de recopier les fichiers ailleurs (avec perte des noms de fichiers et des répertoires d'origine). Il y a aussi foremost dans le même style mais que je n'ai jamais pratiqué.

En tout cas, voilà une faiblesse de l'ext4 mise à jour. resize2fs aurait du refuser l'opération dans ces conditions. et fsck aurait du se déclarer incompétent.
C'est aussi malheureusement la démonstration que le raid n'est pas une solution de sauvegarde...

Edit : Un conseil monte toujours ta partition en readonly tant que tu n'a pas terminé ton opération de récupération. autrement tu risque de "manger" encore plus de bouts de fichiers qui pourraient être retrouvé par photorec.

Dernière modification par jamesbad000 (Le 03/04/2013, à 23:32)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#4 Le 04/04/2013, à 08:04

zapan999

Re : ext4 hs après un grow mdadm puis resize2fs

tout d'abord, merci de ton temps pris à me répondre Jamesbad000.

concernant Photorec, Foremost ou autre outils de récupération de données, je n'ai hélas pas la place disponible pour une récupération autre que "à la volée"

Le plus curieux, c'est que resize2fs donne bien le message d'erreur sur une console sur le serveur. Hélas, j'étais en SSH, et je n'ai pas eut de message de resize2fs hmm


De mon côté, j'ai grandement avancer: récupération total des données, avec mon ancienne taille de partition (le deuxième superblock était un bon pari wink )
je pense que j'ai eut de la chance dans mon malheur...

Un peu de détail, si je post, ce n'est pas que pour avoir de l'aide, mais aussi laisser une trace de ce qui a fonctionner chez moi, au cas ou ca puisse aider un autre wink

un df -Th me donnais un résultat du genre 18Tb 17%occupé.
donc:
- démontage de la partition.

les étapes suivantes ont été trouvées ici
- récupération de la liste des superblock...

dumpe2fs /dev/md0 | grep -i superblock

- tentative de montage de la partition avec un de ces superblock de secours:

mount -o sb=32768 /dev/md0 /mnt/recovery

là, il m'envoie me faire voir, erreur sur la partition... blah blah pas propre...

- laissons voir ce que e2fsck va me dire...

e2fsck -f -b 98304 /dev/sda5

il mouline pendant un bout de temps, me sors 2 inodes doublement alloués (ca me changes des milliers d'erreur du débu), j'accepte les corrections

- je remount:

mount /dev/md0 /mnt/raid0

et là, un petit df -Th me charme avec de joli mots:
15TB, 84% d'occupation...
il m'a poser mes répertoires qui étaient à la racine dans lost+found, donc nickel!

je lance quelques vidéos et fichiers compressés, ca à l'air de rouler... => je me connect à fdj.fr et je prend 3 tickets d'euro millions (oui, à un moment, il faut tirer profit de sa chance wink )


Donc me revoilà au point de départ de mon problème de taille de partition...
Je fait un prochain post sur les infos que je glane et que je recoupe en ce moment, sur les possibilitée d'un resize2fs fonctionnant en 64bits (donc exit la limite des 16To), sous le noyau 3.7, ou la conversion vers du btrfs, xfs ou jfs...
ou arrêter de jouer avec le feu, et simplement baisser la tête et juste créer une autre partition.... mais je suis trop con pour ca je crois hmm

Cordialement,

zapan999

Dernière modification par zapan999 (Le 04/04/2013, à 08:30)

Hors ligne