vi behöver fixa filsystemskada på SDB på redhat 6-version
sdb är xfs-filsystem
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data eftersom data på sdb är enorma
vi vill veta vad är det bästa alternativet 1 eller 2?
eller någon annan idé att fixa filsystemet?
alternativ 1
umount /data fsck -y /dev/sdb mount /data alternativ 2
umount /data e2fsck -y /dev/sdb mount /data alternativ 3
umount /data xfs_repair /dev/sdb mount /data sekund – vilka är riskerna när man gör fsck på enorma data?
Kommentarer
Svar
Citera detta SuperUser-inlägg :
fsckär bara det ursprungliga namnet. När de kom ut med nya filsystem skulle de behöva ett specifikt verktyg för var och en,efsckför ext,e2fsckför ext2,dosfsck,fsckvfat. Så de gjordefsckfronten som bara ringer det som är lämpligt verktyg.
fsck.xfs är förmodligen det du är ute efter.
XFS-relaterad uppdatering:
xfs_check och xfs_repair ska hjälpa dig att utvärdera skadan och reparera om möjligt.
Se manualsidorna för specifik användningsinformation.
Kommentarer
- så att vi kan vara säkra när vi gör det – fsck -y / dev / sdb?
- @yael Det beror på att jag personligen tror att det är det, men det här är troligtvis opinionsbaserat.
- så vad är bättre fsck .xfs -y / dev / sdb eller fsck -y / dev / sdb
- @yael Jag tror att båda skulle göra samma jobb. Men jag brukar alltid ange typen, dvs. Jag skulle använda
fsck.xfs. - så vad är skillnaden mellan xfs_repair till fsck.xfs?
Svara
Till dem som röstar på fsck.xfs … det är bara en bytt namn på / bin / true. Det gör ingenting förutom att returnera ”0” och avsluta Det rätta svaret är:
umount /data xfs_repair /dev/sdb mount /data Kommentarer
- Du märker att xfs_repair nämndes i annat svar
e2fsckpå det?