fsck sur un périphérique raid linux (mandriva)

Le
François Tricard
Bonjour,

Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve
sur un disque miroré via le raid linux (mdadm). Un shutdown -F a
effectivement fait un fsck au boot mais j'ai l'impression qu'il a été
vraiment rapide et minimaliste et je ne trouve pas de log pour savoir ce
qu'il a vraiment fait.

Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var Je ne sais pas comment
m'y prendre. J'ai cru comprendre qu'il était aussi possible de booter
sur un live cd ou un cd d'install en mode rescue.

A vous lire,

François.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #1901091
Salut,


Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve
sur un disque miroré via le raid linux (mdadm...).


Les volumes RAID ne s'appellent pas plutôt mdX ?

Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var


Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.

François Tricard
Le #1901086
Salut,


Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).


Les volumes RAID ne s'appellent pas plutôt mdX ?

oui, mais là je parle d'un disque précis et d'une partion précise.


Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var


Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.


Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?


Michel Tatoute
Le #1901083
François Tricard wrote:

Salut,


Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).


Les volumes RAID ne s'appellent pas plutôt mdX ?

oui, mais là je parle d'un disque précis et d'une partion précise.


Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var


Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.


Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?


si ton disque fait partie d'un raid ca ne va pas le faire.

de toute façon un disque qui fait des bads blocks est juste bon pour la
poubelle (les bad blocks étant la partie émergée du problème).

Donc tu recupere les infos et tu change le disque.

Y a t'il des informations importantes dessus?

Par ailleurs je ne vois pas bien ce que peut apporter un mirroring
sur /var ? Généralement les données sur /var sont temporaires et de peu de
valeur... non?

Michel.



Pascal Hambourg
Le #1901078
François Tricard wrote:

Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).


Les volumes RAID ne s'appellent pas plutôt mdX ?


oui, mais là je parle d'un disque précis et d'une partion précise.



Tu veux dire que hdc8 est une partition RAID qui fait partie d'un volume
RAID 1 mdX, lui-même monté en tant que /var ?

[...]
j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?



Petite précision : fsck ne corrige pas les blocs défecteux, il ne fait
que les marquer pour qu'ils ne soient plus utilisés par le système de
fichiers.

si ton disque fait partie d'un raid ca ne va pas le faire.


Déjà il ne faut pas exécuter fsck -c sur la partition physique (hdc8)
mais sur le volume RAID (mdX) qui contient le système de fichiers.
Ensuite, le RAID 1 risque de cacher des blocs défectueux. En effet lors
d'une opération de lecture un bloc du volume RAID 1 est lu sur une seule
des deux partitions physiques. Si le bloc défectueux correspondant se
trouve sur l'autre partition physique, il passe inaperçu. On peut
vérifier le volume plusieurs fois, mais ça ne garantit pas que tous les
blocs défectueux seront détectés. On peut éventuellement contourner le
problème en sortant la partition saine du RAID avant de lancer la
vérification, puis en la réintégrant et en répliquant le contenu de la
partition qui a subi la vérification. Sinon, il y a peut-être moyen
d'utiliser la liste des blocs trouvés par badblocks sur la partition
physique en la fournissant à fsck, mais ça me semble délicat : il faut
notamment prendre en compte la taille de bloc du système de fichiers,
l'offset du début du volume par rapport au début de la partition...

de toute façon un disque qui fait des bads blocks est juste bon pour la
poubelle (les bad blocks étant la partie émergée du problème).


Je ne serais par aussi catégorique. J'ai récupéré pour mon usage
personnel plusieurs disques poubellisés pour cause de secteurs
défectueux. La plupart continuent de fonctionner normalement après
tentative de réparation (en fait réallocation) des secteurs défectueux
et le cas échéant marquage de ceux qui n'ont pu être réparés. On entend
souvent qu'une fois que des secteurs défectueux apparaissent, ça ne fait
qu'empirer. Ce n'est pas ce que je constate. Il faut regarder les
informations SMART du disque concernant la réallocation des secteurs. Si
des secteurs défectueux deviennent visibles parce que la réserve est
épuisée et que le nombre de secteurs réalloués a atteint son maximum,
alors effectivement le disque est cuit. Dans le cas contraire, j'ai
plutôt l'impression que des secteurs défectueux peuvent apparaître,
probablement dans certaines conditions de stress (température trop
élevée, alimentation instable...), sans impact sur la durée de vie du
disque.

Au final c'est à chacun de voir, en fonction du prix qu'il accorde à ses
données.

Par ailleurs je ne vois pas bien ce que peut apporter un mirroring
sur /var ?


La même chose que le mirroring du swap : une meilleure disponibilité du
système.

Généralement les données sur /var sont temporaires et de peu de
valeur... non?


Euh, il me semble qu'il peut y avoir des trucs assez importants dans
/var, comme tout ce qui concerne la gestion des paquetages, la racine du
site web, les bases de données... Et même s'il n'y a que des trucs
temporaires sans importance, les applications qui s'en servent risquent
de beaucoup moins bien marcher en cas de perte du disque la contenant.




Mihamina (R12y) Rakotomandimby
Le #1901077
Pascal Hambourg wrote:
Généralement les données sur /var sont temporaires et de peu de
valeur... non?
Euh, il me semble qu'il peut y avoir des trucs assez importants dans

/var, comme tout ce qui concerne la gestion des paquetages, la racine du
site web, les bases de données...


/var/www, /var/lib/mysql,...
Si c'est pas important ça,...


Nicolas George
Le #1901076
R12y wrote in message
/var/www, /var/lib/mysql,...


Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.

Mihamina (R12y) Rakotomandimby
Le #1901075
Nicolas George wrote:
R12y wrote in message
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée

baroque de le mettre dans /var.


Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.


Mihamina (R12y) Rakotomandimby
Le #6064791
Nicolas George wrote:
R12y wrote in message
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée

baroque de le mettre dans /var.


Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.


Jerome Lambert
Le #6064781
Nicolas George wrote:
R12y wrote in message
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée

baroque de le mettre dans /var.


Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.


Pour l'organisation des fichiers, il y a eu ici récemment toute une
discussion là-dessus, notamment avec S.T. En gros, il y a deux approches:
1) on suit les recommandations des développeurs du programme initial,
donc si la doc dit de mettre les fichiers à tel endroit, on les y met
même si c'est une ineptie. Cette façon de procéder permet de mieux s'y
retrouver en cas de parc (très) hétérogène, les fichiers étant au même
endroit quel que soit le Unix ou la distribution utilisé.

2) on respecte les standards de l'arborescence, et vu que /var/ est
censé cotenir des données modifiables pendant l'exécution, donc pour
reprendre l'exemple d'apache /var/www est effectivement une ineptie. De
cette manière l'arborescence reste claire et logique, mais alors chaque
Unix/distribution Linux risque de poposer *sa* solution alternative. La
doc d'apache stipule /usr/local/apache/htdocs comme défaut, mais donne
aussi l'exemple de /usr/web comme alternative, FreeBSD met comme défaut
/usr/local/www/data, MacOS X /Library/WebServer/Documents et j'ai aussi
vu passer des /home/httpd.



nicolas vigier
Le #6064731
On 2007-09-06, Jerome Lambert

2) on respecte les standards de l'arborescence, et vu que /var/ est
censé cotenir des données modifiables pendant l'exécution, donc pour
reprendre l'exemple d'apache /var/www est effectivement une ineptie. De


Pourquoi une ineptie ? Tu ne modifies jamais tes pages web ?
Pour moi /var contient toutes les données qui peuvent etre modifiées
(ca correspond aux pages d'un serveur web). /usr ne contient que des
données qui proviennent du système (de packages) et que l'on a aucun
interet à backuper.

Publicité
Poster une réponse
Anonyme