Systèmes de fichiers sous Linux : commandes pour gérer EXT4, XFS et BTRFS
Table des matières
Parfois quand le système de fichiers est incohérent, il est nécessaire de faire une vérification.
Sous Linux, avec des partitions ext2 ext3 ou ext4 on utilise l'utilitaire fsck.
Par analogie, sous Windows, la commande est chkdsk
La règle d'or pour vérifier un système de fichiers est qu'il doit être démonté.
Puis on lance la vérification du système de fichiers :
Si le système de fichiers est noté comme propre on peut forcer la réparation via l'option -f
Le système de fichiers racine ( / ) ne peut être démonté, donc comment le vérifier ?
Il suffit de créer le fichier forcefsck à la racine :
Cela aura pour but de vérifier le système de fichier racine au prochain redémarrage, puis des systèmes de fichiers qui ont le chiffre 2 indiqué en bout de ligne du fichier fstab (Voir fstab : Explications sur le fichier et sa structure )
Parfois lors du démontage du système de fichiers, on a une erreur :
Pour diagnostiquer, on va utiliser la commande fuser en spécifiant le point de montage concerné :
Le processus en cause est le 3614.
On recherche le processus concerné :
La réponse de la console :
Ici c'est squid qui est en cause, mais dans votre cas adaptez.
Moi j'ai donc arrêté squid3 :
Puis démonté ma partition home avec succès
Puis faire ma vérification de système de fichiers.
Introduction
Parfois quand le système de fichiers est incohérent, il est nécessaire de faire une vérification.
Sous Linux, avec des partitions ext2 ext3 ou ext4 on utilise l'utilitaire fsck.
Par analogie, sous Windows, la commande est chkdsk
Vérifier les systèmes de fichiers
La règle d'or pour vérifier un système de fichiers est qu'il doit être démonté.
Code BASH :
umount /home
Puis on lance la vérification du système de fichiers :
Code BASH :
fsck /dev/sda1
Code TEXT :
fsck de util-linux 2.20.1 e2fsck 1.42 (29-Nov-2011) /dev/sda1 : propre, 24000/1250928 fichiers, 1940811/5002231 blocs
Si le système de fichiers est noté comme propre on peut forcer la réparation via l'option -f
Code BASH :
fsck -f /dev/sda1
Code TEXT :
fsck de util-linux 2.20.1 e2fsck 1.42 (29-Nov-2011) 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/sda1 : 24000/1250928 fichiers (0.7% non contigüs), 1940811/5002231 blocs
Vérifier le système de fichiers racine
Le système de fichiers racine ( / ) ne peut être démonté, donc comment le vérifier ?
Il suffit de créer le fichier forcefsck à la racine :
Code BASH :
touch /forcefsck
Cela aura pour but de vérifier le système de fichier racine au prochain redémarrage, puis des systèmes de fichiers qui ont le chiffre 2 indiqué en bout de ligne du fichier fstab (Voir fstab : Explications sur le fichier et sa structure )
Comment démonter un système de fichiers occupé ?
Parfois lors du démontage du système de fichiers, on a une erreur :
Code BASH :
umount /home
Code TEXT :
démontage : /home : périphérique occupé. (Dans certains cas, des infos sur les processus l'utilisant sont récupérables par lsof(8) ou fuser(1))
Pour diagnostiquer, on va utiliser la commande fuser en spécifiant le point de montage concerné :
Code BASH :
fuser -m /home /home: 3614
Le processus en cause est le 3614.
On recherche le processus concerné :
Code BASH :
ps -ef | grep 3614
La réponse de la console :
Code TEXT :
proxy 3614 1 0 11:20 ? 00:00:00 /usr/sbin/squid3 -N -YC -f /etc/squid3/squid.conf proxy 3615 3614 0 11:20 ? 00:00:00 (unlinkd) root 3621 1963 0 11:21 pts/1 00:00:00 grep --color=auto 3614
Ici c'est squid qui est en cause, mais dans votre cas adaptez.
Moi j'ai donc arrêté squid3 :
Code BASH :
/etc/init.d/squid3 stop
Puis démonté ma partition home avec succès
Code BASH :
umount /home
Puis faire ma vérification de système de fichiers.
Code BASH :
fsck -f /dev/sda1