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 :
fsckis alleen de originele naam. Toen ze met nieuwe bestandssystemen uitkwamen, hadden ze voor elk een specifieke tool nodig,efsckvoor ext,e2fsckvoor ext2,dosfsck,fsckvfat. Dus maakten zefsckde 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.xfsgebruiken. - 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
e2fsckerop uit te voeren?