[débutant] réparer une partition

Support Debian
#1

Bonjour,

Depuis quelques temps mon disque se met parfois directement en mode lecture, ce qui a pour conséquence
un plantage de beaucoup d’applicatifs (Open-xchange, apache, samba…)

voici deux aperçus du fichier var/log/messages

Apr 29 14:13:28 debian kernel: EXT3-fs warning: mounting fs with errors, running e2fsck is recommended Apr 29 14:13:28 debian kernel: EXT3 FS on dm-0, internal journal Apr 29 14:13:28 debian kernel: EXT3-fs: recovery complete. Apr 29 14:13:28 debian kernel: EXT3-fs: mounted filesystem with ordered data mode.

Apr 29 14:15:31 debian kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended Apr 29 14:15:31 debian kernel: EXT3 FS on sdb1, internal journal Apr 29 14:15:31 debian kernel: EXT3-fs: mounted filesystem with ordered data mode.

je sais qu’il faut démonter le disque par la commande umount /dev/sdb1
et ensuite lancé la commande pout vérifier la partition e2fsck -y /dev/sdb1
Mes deux commandes sont-elles sans danger ?

Mais avant tout, il faut vérifier si l’erreur vient du système de fichiers ou du disque (ex: /dev/sdx), car essayer de réparer un système de fichiers sur un disque défectueux peut avoir des conséquences catastrophiques.
j’ai donc juste relever ceci grâce à la commande dmesg:

EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on sdb1, internal journal EXT3-fs: mounted filesystem with ordered data mode.

#2

Salut,

Comme bien sûr tu as une sauvegarde complète de tes données, ces deux commandes sont non seulement sans danger mais au contraire, comme le dit ce message "recommandée.

[quote]
maximal mount count reached, running e2fsck is recommended[/quote]

Selon ce que contient sdb1 tu vas pouvoir la démonter ou il te faudra passer par l’intermédiaire d’un cd-live. Surtout ne pas appliquer ces commandes sur une partion non démontée :slightly_smiling:

#3

merci de ta réponse

non je n’ai pas sauvegardé mes données mais je vais le faire

peux tu aussi me confirmer que la commande suivante est sans danger même
sans sauvegarde ? car je suis impatient d’essayer sans sauvegarder

e2fsck -n /dev/sdb1
-n : Mode automatique : on ne fait que vérifier

une autre question :

e2fsck -f /dev/sdb1
-f : Force une vérification approfondie
-y : Mode automatique : on répare

Qui a t-il comme différence entre l’option -f (force) et -y (automatique) ? je ne vois pas

d’avance merci :038

#4

[quote=“junior2”]merci de ta réponse

non je n’ai pas sauvegardé mes données mais je vais le faire

peux tu aussi me confirmer que la commande suivante est sans danger même
sans sauvegarde ? car je suis impatient d’essayer sans sauvegarder

e2fsck -n /dev/sdb1
-n : Mode automatique : on ne fait que vérifier

une autre question :

e2fsck -f /dev/sdb1
-f : Force une vérification approfondie
-y : Mode automatique : on répare

Qui a t-il comme différence entre l’option -f (force) et -y (automatique) ? je ne vois pas

d’avance merci :038[/quote]

Salut,

-n Effectivement ne rectifiera rien. Il vérifiera et répondra automatiquement “non” à toutes les demandes de réparations;
-f Démarre la vérification même s’il ne semble pas y avoir d’erreur dans la partition, mais te laissera la main aux questions;
-y Vérifie et répare (il répond automatiquement “oui” à toutes les demandes de réparations.

Je n’ai rien inventé, c’est dans le man !

#5

Un e2fsck -y est quasi sans danger sur une partition démontée, mais quasi suicidaire sur une partition montée

L’idéal est un live cd de knoppix, tu ouvre un terminal, te logue en root (pas de password requis), puis à l’aide des commandes fdisk -l et df -h (si elles sont montées) tu identifies tes partitions. Ensuite tu les démontes avec umount et go pour le e2fsck -y.

Si ça peut te rassurer, ça fait près de 2ans que je fais des e2fsck -y au moins 1 à 2 fois par semaine sur des partoch démontées avec knoppix et je n’ai jamais eu un problème ! Si ça répare rien, ou que ça chie, c’est que le disque va pas tarder à claquer…

#6

Pour plus de sécurité, démarre en single mode.
Démonte la partition concerné.

#7

Ok merci à tous d’avoir répondu

Je vais essayer et vous tiens au courant.

Marc

#8

Personnellement j’enlèverais le mot quasi de ta phrase :slight_smile:

#9

bonjour,

je reviens vers vous en tapant la commande df -TH

root@debian:~ # df -Th Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur /dev/sda1 ext3 32G 12G 20G 37% / tmpfs tmpfs 506M 0 506M 0% /lib/init/rw udev tmpfs 10M 60K 10M 1% /dev tmpfs tmpfs 506M 0 506M 0% /dev/shm /dev/mapper/datas-samba ext3 247G 154G 81G 66% /mnt/partage/samba /dev/mapper/datas-vmail ext3 99G 11G 83G 12% /mnt/partage/vmail

ce qui m’intéresse c’est de réparer la les partitions datas-samba et datas-vmail …

si je fais un umount /dev/mapper/datas-samba à la place
de umount /mnt/partage/samba

c’est aussi bon pour le démontage ?

et après je lance la vérification sur /dev/mapper/datas-samba ou sur /mnt/partage/samba ?

et quand une partition est occupée on fait comment ?

root@debian:~ # umount /dev/mapper/datas-samba umount: /mnt/partage/samba: device is busy umount: /mnt/partage/samba: device is busy

Marc

#10

Re,

C’est dans partage que se trouve la partition, les deux "datas sont des vg “virtual group” :slightly_smiling:

#11

Peu importe pour le démontage.

umount /point/de/montage umount /chemin/périférique
Les deux commandes fonctionneront.

Par contre, pour ta vérification, tu dois lancer le fsck sur ton filesystem, pas sur ton point de montage.

#12

[size=100]question à ggoodluck47 [/size]

Comment sais tu que ce sont des virtual group les deux datas ?
est ce que les deux datas sont des partitions ?

[size=100]question à Knard[/size]

quand tu dis lancer la commande sur mon filesystem tu veux dire qu’il faut faire dans mon
cas : e2fsck -f /dev/mapper/datas-vmail
c’est quoi pour toi la différence entre la e2fsck et fsck ?

Cordialement
Marc

#13

Très bonne question.
J’ai toujours utilisé fsck. Je crois que e2fsck est exactement la même chose que fsck mais spécialisé dans les système de fichier ext2 et ext3.
Quand je lance un fsck sur un system de fichier ext3, il détecte le type et me lance lui-même e2fsck.

Mais j’avoue que je ne connais pas de réelles différences concrètes, c’est plus une question d’habitude.

fsck -f -y /dev/mapper/vgtux-name fsck 1.41.3 (12-Oct-2008) e2fsck 1.41.3 (12-Oct-2008) Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe /dev/mapper/vgtux-name : 11/327680 fichiers (0.0% non contigus), 55935/1310720 blocs

#14

Salut,

Je viens de supprimer ma réponse erronée :blush:

#15

Je peux te dire que ce sont des LV parce qu’ils sont dans le répertoire /dev/mapper. De plus, ces LV font partie du VG “datas”.

Non, ce ne sont pas des partitions. Une partition est une segmentation d’un disque. Ce sont des LV (volumes logiques) que tu as remplis d’un filesystem.

#16

et quand une partition est occupée on fait comment pour la démonter ?

root@debian:~ # umount /dev/mapper/datas-samba umount: /mnt/partage/samba: device is busy umount: /mnt/partage/samba: device is busy

Marc

#17

Re,

lvdisplay pour voir les noms des lvm qui ne comportent jamais “mapper”

#18

Pour connaître les processus qui occupe ton périphérique:

[code]deb-laptop:~# lvdisplay
— Logical volume —
LV Name /dev/vgtux/boot
VG Name vgtux
LV UUID A3lYPD-ieTc-elYq-Kf6u-Y7LQ-jpK1-KtMeYe
LV Write Access read/write
LV Status available

open 1

LV Size 44,00 MB
Current LE 11
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:0

— Logical volume —
LV Name /dev/vgtux/root
VG Name vgtux
LV UUID QNX3QQ-Hcma-3AIS-2Z6f-JbQu-fzse-2C4Iaa
LV Write Access read/write
LV Status available

open 1

LV Size 476,00 MB
Current LE 119
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:1

— Logical volume —
LV Name /dev/vgtux/tmp
VG Name vgtux
LV UUID Y7XsbJ-NAMk-H1gh-hQJj-rcdp-yM8P-N4DFLa
LV Write Access read/write
LV Status available

open 1

LV Size 188,00 MB
Current LE 47
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:2

— Logical volume —
LV Name /dev/vgtux/usr
VG Name vgtux
LV UUID jAZOq4-gHRR-Ny9F-EEyk-BKKr-GRI4-dABmfI
LV Write Access read/write
LV Status available

open 1

LV Size 4,66 GB
Current LE 1192
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:3

— Logical volume —
LV Name /dev/vgtux/var
VG Name vgtux
LV UUID Dzfq66-Znb2-tfno-s5yo-sZai-U4YH-nRAPlv
LV Write Access read/write
LV Status available

open 1

LV Size 1,86 GB
Current LE 476
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:4

— Logical volume —
LV Name /dev/vgtux/home
VG Name vgtux
LV UUID 08eXcR-IrJA-mWTf-qTh7-tN7s-cyUQ-JiNNP9
LV Write Access read/write
LV Status available

open 1

LV Size 27,94 GB
Current LE 7152
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:5

— Logical volume —
LV Name /dev/vgtux/swap
VG Name vgtux
LV UUID V3QoKf-t1gj-dJjl-CqGp-BxuD-fskz-Ww67bS
LV Write Access read/write
LV Status available

open 2

LV Size 976,00 MB
Current LE 244
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:6

— Logical volume —
LV Name /dev/vgtux/vbox
VG Name vgtux
LV UUID wzfDB4-aVXv-c23y-TDeS-c7es-6nw8-HPyTRW
LV Write Access read/write
LV Status available

open 1

LV Size 20,00 GB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto

  • currently set to 256
    Block device 254:7[/code]

Pas de mapper ??? C’est vrai mais …

deb-laptop:~# ls -lh /dev/vgtux/ total 0 lrwxrwxrwx 1 root root 22 mai 11 18:49 boot -> /dev/mapper/vgtux-boot lrwxrwxrwx 1 root root 22 mai 11 18:49 home -> /dev/mapper/vgtux-home lrwxrwxrwx 1 root root 22 mai 11 18:49 root -> /dev/mapper/vgtux-root lrwxrwxrwx 1 root root 22 mai 11 18:49 swap -> /dev/mapper/vgtux-swap lrwxrwxrwx 1 root root 21 mai 11 18:49 tmp -> /dev/mapper/vgtux-tmp lrwxrwxrwx 1 root root 21 mai 11 18:49 usr -> /dev/mapper/vgtux-usr lrwxrwxrwx 1 root root 21 mai 11 18:49 var -> /dev/mapper/vgtux-var lrwxrwxrwx 1 root root 22 mai 11 18:49 vbox -> /dev/mapper/vgtux-vbox

Les informations données par lvdisplay ne sont que les liens symboliques des fichiers périphériques.
cqfd

#19

Re,

Et c’est comme ceci qu’il faut désigner les /dev ! Je n’y suis pour rien mais je travaille sous LVM depuis plus d’un an :slightly_smiling:

#20

[quote=“ggoodluck47”]Re,

Et c’est comme ceci qu’il faut désigner les /dev ! Je n’y suis pour rien mais je travaille sous LVM depuis plus d’un an :slightly_smiling:[/quote]

J’y suis depuis autant de temps si pas plus, les deux fonctionnent très bien, je peux te l’assurer.
Je n’ai pour ainsi dire jamais utiliser /dev/vgtux/home mais toujours /dev/mapper/vgtux-home et je n’ai jamais eu de soucis. Que ce soit dans mon fstab ou dans mes opérations de redimensionnement.
Je me demande d’ailleurs pourquoi on ne pourrait pas utiliser les fichiers de périphériques directement au lieu de leur lien symbolique.
Les deux fonctionnent très bien, c’est juste une question de préférences.