nous devons corriger la corruption du système de fichiers sur sdb sur la version redhat 6
sdb est un système de fichiers xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data car les données sur sdb sont énormes
nous voulons savoir quelle est la meilleure option 1 ou 2?
ou une autre idée pour corriger le système de fichiers?
option 1
umount /data fsck -y /dev/sdb mount /data option 2
umount /data e2fsck -y /dev/sdb mount /data option 3
umount /data xfs_repair /dev/sdb mount /data deuxième – quels sont les risques lorsque vous faites fsck sur des données volumineuses?
Commentaires
Réponse
Citant ce message de superutilisateur :
fsckest juste le nom dorigine. Lorsquils sortiraient de nouveaux systèmes de fichiers, ils auraient besoin dun outil spécifique pour chacun deux,efsckpour ext,e2fsckpour ext2,dosfsck,fsckvfat. Ils ont donc fait defscklinterface qui appelle simplement loutil approprié.
fsck.xfs est probablement ce que vous recherchez.
Mise à jour liée à XFS:
xfs_check et xfs_repair devraient vous aider à évaluer les dégâts et réparer si possible.
Veuillez consulter les pages de manuel pour des informations dutilisation spécifiques.
Commentaires
- afin que nous puissions être en sécurité quand on fait – fsck -y / dev / sdb?
- @yael Cela dépend, je pense personnellement que oui, mais cest probablement basé sur une opinion.
- alors quest-ce qui est mieux fsck .xfs -y / dev / sdb ou fsck -y / dev / sdb
- @yael Je pense que les deux feraient le même travail. Mais jai tendance à toujours spécifier le type, cest à dire. Jutiliserais
fsck.xfs. - alors quel est le diff entre xfs_repair et fsck.xfs?
Réponse
Aux personnes qui votent pour fsck.xfs … cest juste une version renommée de / bin / true. Elle ne fait rien sauf retourner « 0 » et quitter . La bonne réponse est:
umount /data xfs_repair /dev/sdb mount /data Commentaires
- Vous remarquerez que xfs_repair a été mentionné dans l autre réponse
e2fsckdessus?