we moeten de corruptie van het bestandssysteem op sdb op redhat 6 versie herstellen
sdb is xfs-bestandssysteem
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data
omdat de gegevens op sdb enorm zijn
we willen weten wat is de beste optie 1 of 2?
of een ander idee om het bestandssysteem te repareren?
optie 1
umount /data fsck -y /dev/sdb mount /data
optie 2
umount /data e2fsck -y /dev/sdb mount /data
optie 3
umount /data xfs_repair /dev/sdb mount /data
ten tweede – wat zijn de risicos bij het uitvoeren van fsck op enorme gegevens?
Reacties
Antwoord
Onder vermelding van deze SuperUser-post :
fsck
is alleen de originele naam. Toen ze met nieuwe bestandssystemen uitkwamen, hadden ze voor elk een specifieke tool nodig,efsck
voor ext,e2fsck
voor ext2,dosfsck
,fsckvfat
. Dus maakten zefsck
de front-end die alleen de juiste tool aanroept.
fsck.xfs
is waarschijnlijk wat u zoekt.
XFS-gerelateerde update:
xfs_check
en xfs_repair
zouden u moeten helpen bij het evalueren van de schade en indien mogelijk repareren.
Zie de handleidingpaginas voor specifieke gebruiksinformatie.
Opmerkingen
- zodat we veilig kunnen zijn wanneer we dat doen – fsck -y / dev / sdb?
- @yael Dat hangt ervan af, persoonlijk denk ik van wel, maar dit is waarschijnlijk gebaseerd op meningen.
- dus wat is beter fsck .xfs -y / dev / sdb of fsck -y / dev / sdb
- @yael Ik denk dat beide hetzelfde werk zouden doen. Maar ik heb de neiging om altijd het type te specificeren, dwz. Ik zou
fsck.xfs
gebruiken. - dus wat is het verschil tussen xfs_repair en fsck.xfs?
Antwoord
Aan de mensen die stemmen voor fsck.xfs … het is gewoon een hernoemde versie van / bin / true. Het doet niets behalve “0” teruggeven en afsluiten . Het juiste antwoord is:
umount /data xfs_repair /dev/sdb mount /data
Reacties
- U zult zien dat xfs_repair werd genoemd in het ander antwoord
e2fsck
erop uit te voeren?