[RESOLU] RAID6 - plus d'accès aux données

rbn8 · Le 21/06/2017, à 23:44

Je dois avouer ne pas avoir tout compris sur ce bug, mais ce n'est pas grave.

J'ai téléchargé la dernière release de Ubuntu il y a deux jours pour installer cette VM.
Le système est donc pratiquement à jour.

sudo lsb_release -a

robin@WS2012-Ubuntu:~$ sudo lsb_release -a
[sudo] Mot de passe de robin : 
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

sudo apt-get update

robin@WS2012-Ubuntu:~$ sudo apt-get update 
Atteint:1 http://fr.archive.ubuntu.com/ubuntu xenial InRelease
Réception de:2 http://fr.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Réception de:3 http://fr.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]
Réception de:4 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Réception de:5 http://fr.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [565 kB]
Réception de:6 http://fr.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [547 kB]
Réception de:7 http://fr.archive.ubuntu.com/ubuntu xenial-updates/main amd64 DEP-11 Metadata [299 kB]
Réception de:8 http://fr.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [195 kB]
Réception de:9 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [291 kB]
Réception de:10 http://fr.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [488 kB]
Réception de:11 http://fr.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [470 kB]
Réception de:12 http://fr.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 DEP-11 Metadata [163 kB]
Réception de:13 http://fr.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [208 kB]
Réception de:14 http://fr.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 DEP-11 Metadata [2 520 B]
Réception de:15 http://fr.archive.ubuntu.com/ubuntu xenial-backports/main amd64 DEP-11 Metadata [3 324 B]
Réception de:16 http://fr.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 Packages [5 804 B]
Réception de:17 http://fr.archive.ubuntu.com/ubuntu xenial-backports/universe i386 Packages [5 812 B]
Réception de:18 http://fr.archive.ubuntu.com/ubuntu xenial-backports/universe Translation-en [3 004 B]
Réception de:19 http://fr.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata [4 672 B]
Réception de:20 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [275 kB]
Réception de:21 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [124 kB]
Réception de:22 http://security.ubuntu.com/ubuntu xenial-security/main amd64 DEP-11 Metadata [54,6 kB]
Réception de:23 http://security.ubuntu.com/ubuntu xenial-security/main DEP-11 64x64 Icons [45,7 kB]
Réception de:24 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [139 kB]
Réception de:25 http://security.ubuntu.com/ubuntu xenial-security/universe i386 Packages [125 kB]
Réception de:26 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 DEP-11 Metadata [35,7 kB]
Réception de:27 http://security.ubuntu.com/ubuntu xenial-security/universe DEP-11 64x64 Icons [57,0 kB]

sudo apt-get dist-upgrade

robin@WS2012-Ubuntu:~$ sudo apt-get dist-upgrade 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  linux-headers-4.8.0-36 linux-headers-4.8.0-36-generic linux-image-4.8.0-36-generic
  linux-image-extra-4.8.0-36-generic snap-confine
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants seront mis à jour :
  libnss3 libnss3-nssdb
2 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

Je te prépare ce mail.

Dernière modification par rbn8 (Le 21/06/2017, à 23:46)

jamesbad000 · Le 22/06/2017, à 00:32

Ok, rien a espérer du coté d'une simple mise à jour donc.
Sinon pour le contenu du log, je dirais; Sacré bordel la dedans

En tout cas, à ce stade, je ne vois pas vraiment de solution pour faire mieux qu'attendre que ça se passe.

Autrement, il faudrait reprendre le fsck en mode réponse manuel, et répondre "y" à des milliers de messages avant d'arriver à la partie ou il faudrait répondre "n" aux messages concernant les fichiers qu'on ne veut pas réparer.

Bon la nuit porte conseil...

rbn8 · Le 22/06/2017, à 18:46

Bonjour,

Mon petit post quotidien pour tenir informé des avancements.

J'ai été un peu optimiste sur mon calcul, j'en suis à 29 fichiers sur 828 en bientôt 2 jours.
"Attendre que ça se passe", oui mais attendre 2 mois..?
On est en dessous des un fichier par heure. Est-ce que le fait que seul le CPU3 travaille n'est pas la source de cette lenteur?

Si je reprends le fsck en mode manuel et que je répond "non" sur la partie réparation de fichier, qu'est-ce que cela va apporter?
Est-ce que l'accès à la partition sera réparée, ce qui me permettra de supprimer une majorité des fichiers posant problème?

Je préfère y passer du temps que d'attendre pendant 2mois que ça se passe. Et qui sait ce qu'il peut se passer en 60 jours, on est pas à l'abri d'une coupure de courant ou autre problème.
De ce que j'ai compris, ces erreurs dans le terminal ne vont pas nous simplifier la tâche. J'imagine que même une fois arrivé à la fin du fsck, on est pas assuré d'une réparation de la partition?

PS: oui le fichier log est plutôt balèze
Mais je suis content que mes photos et mes études ne soient pas dans la liste.

Pour le moment, ça tourne.

Merci.

Dernière modification par rbn8 (Le 22/06/2017, à 18:55)

jamesbad000 · Le 22/06/2017, à 20:46

J'ai été un peu optimiste sur mon calcul, j'en suis à 29 fichiers sur 828 en bientôt 2 jours.
"Attendre que ça se passe", oui mais attendre 2 mois..?
On est en dessous des un fichier par heure. Est-ce que le fait que seul le CPU3 travaille n'est pas la source de cette lenteur?

Il est assez probable que le temps n'est pas proportionnel au nombre de fichiers, mais plutôt à la quantité de blocs de données en conflit... Quoiqu'il en soit, en l'absence de meilleurs perspectives, il valait mieux laisser tourner encore un peu...
Quand au fait qu'il n'utilise qu'une CPU, il n'y a rien à faire. La réparation d'un système de fichier est quelque chose de complexe, et la première chose qu'on lui demande c'est d'être fiable. Le multi threading à tendance rend la programation moins clair et moins prévisibles...

Bon je n'ai pas de certitudes absolue. Mais après réflexion, il y a quand même de bonne chance, que les erreurs réparées ne se représenterons pas si on interrompt le fsck et qu'on le relance sans la réponse auto...

Si je reprends le fsck en mode manuel et que je répond "non" sur la partie réparation de fichier, qu'est-ce que cela va apporter?

En sautant les étapes longues, on va gagner du temps

De ce que j'ai compris, ces erreurs dans le terminal ne vont pas nous simplifier la tâche. J'imagine que même une fois arrivé à la fin du fsck, on est pas assuré d'une réparation de la partition?

En tout cas, si je me réfère au bug sur launchpad, il a été possible de supprimer les fichiers en cause à la suite de la réparation, bien que les erreurs se représentait à chaque fsck..

Donc, je suggère d'interrompre le fsck en cours (ctrl+C)

puis pour voir ce qu'il reste comme problème, et si le système de fichier redevenu accessible:

sudo fsck -fn /dev/mapper/volume_1 
sudo mount -ro /dev/mapper/volume_1 /mnt

Dernière modification par jamesbad000 (Le 22/06/2017, à 20:58)

rbn8 · Le 22/06/2017, à 20:59

ctrl c, stop, exit ne provoquent aucune réaction..
Est-ce safe de fermer le terminal?

J'ai tout de même lancé le fsck -fn dans un autre terminal :

"Passe 1 : vérification des i-noeuds, des blocs et des tailles"
=> plus d'erreur !!

"Passe 1B : ré-examen pour les blocs réclamé(s) plusieurs fois"
=> toujours les mêmes? erreurs

"Passe 1C : examen des répertoires pour les i-noeuds avec des blocs réclamé(s) plusieurs fois"
=> toujours aucune erreur

"Passe 1D : ajustement des blocs réclamé(s) plusieurs fois"
=> les fichiers qui ont été corrigés n'apparaissent plus.

Concernant l'activité CPU : j'ai maintenant 2 coeurs qui sont à 100%, qui sont logiquement utilisés par les deux processus fsck (fsck -fy et fsck -fn).
Donc il semblerait bien que fsck ne gère pas le multi threading.

Dernière modification par rbn8 (Le 22/06/2017, à 21:16)

jamesbad000 · Le 22/06/2017, à 21:13

De toute façon, entre ça ou faire un kill, il n'y a pas de garantie.
Par contre avec l'overlay on a toujours l'option de revenir à la situation d'origine...
Vérifie que la cpu revient à un niveau d'inactivité standard après...

rbn8 · Le 22/06/2017, à 21:21

J'ai maintenant fermé les deux terminaux.
Utilisation CPU revenu à la normal.

sudo mount -ro /dev/mapper/volume_1 /mnt
mount: can't find /mnt in /etc/fstab

jamesbad000 · Le 22/06/2017, à 21:24

erreur de ma part

sudo mount -o ro /dev/mapper/volume_1 /mnt

jamesbad000 · Le 22/06/2017, à 21:33

"Passe 1B : ré-examen pour les blocs réclamé(s) plusieurs fois"
=> toujours les mêmes? erreurs

A priori normal, il s'agit des blocs associés à la liste de fichier qui vient plus loin

Dernière modification par jamesbad000 (Le 22/06/2017, à 21:34)

rbn8 · Le 22/06/2017, à 21:42

Excellent le mount est passé! MERCI!

La navigation dans les dossiers est également possible tant que le dossier en question ne contient pas un fichier problématique.
Dois-je / puis-je procéder à la suppression de certains dossiers afin de gagner du temps sur la réparation?

Oui il semble que tu ais raison : Quand on regarde les premières lignes de la seconde étape, il ressort les 8 erreurs que nous avons eu dans le terminal. La suite correspond en toute logique aux fichiers qui n'ont pas encore été traités.

Passe 1B : ré-examen pour les blocs réclamé(s) plusieurs fois
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98319469 : 786473600
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98319972 : 786470282
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98319983 : 786473600
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98320225 : 1050257956
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98320246 : 786470185
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98320247 : 1050257956
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98320249 : 786470282
Bloc(s) réclamé(s) plusieurs fois dans l'i-noeud 98322496 : 786470185

Dernière modification par rbn8 (Le 22/06/2017, à 21:46)

jamesbad000 · Le 22/06/2017, à 22:07

Dois-je / puis-je procéder à la suppression de certains dossiers afin de gagner du temps sur la réparation?

En principe je dirais non, mais comme on travaille avec un filet de sécurité, on peut tenter ce raccourci.

Ensuite relancer le fsck avec seulement l'option -f pour pourvoir choisir la réponse au message d'interrogation

rbn8 · Le 22/06/2017, à 22:18

Je regarderai précisément demain pour les fichiers à supprimer.

Je vais lancer le fsck -f, dois-je répondre "non" à chaque question?

jamesbad000 · Le 22/06/2017, à 22:30

Ca dépend des messages :

Cloner les blocs réclamés plusieurs fois ? non

En conséquence de la réponse non au clonage, il va suivre:
Détruire le fichier ? oui

Pour le reste si la question est corriger ou réparer ? oui

rbn8 · Le 01/09/2017, à 22:07

Bonjour à tous,

En revenant sur le forum, je viens de me rendre compte que je n'avais pas clôturer le sujet :

Jamesbad et moi avons continué de discuter par émail pour résoudre le problème.

Étant donné que l'overlay avait fonctionné, nous avions commencé à suivre une piste : appliquer les modifications de l'overlay sur le volume d'origine.
Finalement, j'ai relancé un fsck.ext4 -f /dev/vg1/volume_1 et j'ai refais la même procédure, c’est à dire répondre manuellement aux erreurs du fsck.

Je tiens à remercier @jamesbad000 pour son aide plus que précieuse, la plupart de mes données étaient intactes.

Peut-être que cette explication aidera des personnes dans le même cas que moi.

Merci.

Dernière modification par rbn8 (Le 01/09/2017, à 22:09)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 21/06/2017, à 23:44

Re : [RESOLU] RAID6 - plus d'accès aux données

#27 Le 22/06/2017, à 00:32

Re : [RESOLU] RAID6 - plus d'accès aux données

#28 Le 22/06/2017, à 18:46

Re : [RESOLU] RAID6 - plus d'accès aux données

#29 Le 22/06/2017, à 20:46

Re : [RESOLU] RAID6 - plus d'accès aux données

#30 Le 22/06/2017, à 20:59

Re : [RESOLU] RAID6 - plus d'accès aux données

#31 Le 22/06/2017, à 21:13

Re : [RESOLU] RAID6 - plus d'accès aux données

#32 Le 22/06/2017, à 21:21

Re : [RESOLU] RAID6 - plus d'accès aux données

#33 Le 22/06/2017, à 21:24

Re : [RESOLU] RAID6 - plus d'accès aux données

#34 Le 22/06/2017, à 21:33

Re : [RESOLU] RAID6 - plus d'accès aux données

#35 Le 22/06/2017, à 21:42

Re : [RESOLU] RAID6 - plus d'accès aux données

#36 Le 22/06/2017, à 22:07

Re : [RESOLU] RAID6 - plus d'accès aux données

#37 Le 22/06/2017, à 22:18

Re : [RESOLU] RAID6 - plus d'accès aux données

#38 Le 22/06/2017, à 22:30

Re : [RESOLU] RAID6 - plus d'accès aux données

#39 Le 01/09/2017, à 22:07

Re : [RESOLU] RAID6 - plus d'accès aux données

Pied de page des forums