trebuie să remediem corupția sistemului de fișiere pe sdb pe versiunea redhat 6
sdb este sistemul de fișiere xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data pentru că datele de pe sdb sunt imense
vrem să știm care este cea mai bună opțiune 1 sau 2?
sau altă idee pentru a repara sistemul de fișiere?
opțiunea 1
umount /data fsck -y /dev/sdb mount /data opțiunea 2
umount /data e2fsck -y /dev/sdb mount /data opțiunea 3
umount /data xfs_repair /dev/sdb mount /data al doilea – care sunt riscurile atunci când faci fsck pe date imense?
Comentarii
Răspundeți
Citând această postare SuperUser :
fsckeste doar numele original. Când au ieșit cu sisteme de fișiere noi, ar avea nevoie de un instrument specific pentru fiecare,efsckpentru ext,e2fsckpentru ext2,dosfsck,fsckvfat. Deci, au făcutfsckfront-end-ul care apelează doar instrumentul potrivit.
fsck.xfs este probabil ceea ce cauți.
Actualizare legată de XFS:
xfs_check și xfs_repair ar trebui să vă ajute să evaluați daunele și reparați dacă este posibil.
Vă rugăm să consultați paginile manualului pentru informații specifice de utilizare.
Comentarii
- pentru a putea fi în siguranță când o facem – fsck -y / dev / sdb?
- @yael Depinde, eu personal cred că este, dar probabil că este bazat pe opinie.
- deci ce este mai bine fsck .xfs -y / dev / sdb sau fsck -y / dev / sdb
- @yael cred că ambii ar face aceeași treabă. Dar tind să specific întotdeauna tipul, adică. Aș folosi
fsck.xfs. - deci care este diferența dintre xfs_repair la fsck.xfs?
Răspuns
Pentru persoanele care votează pentru fsck.xfs … este doar o versiune redenumită a / bin / true. Nu face altceva decât să returneze „0” și să iasă . Răspunsul corect este:
umount /data xfs_repair /dev/sdb mount /data Comentarii
- Veți observa că xfs_repair a fost menționat în alt răspuns
e2fsckpe acesta?