vi trenger å fikse filsystemkorrupsjon på sdb på redhat 6-versjon
sdb er xfs filsystem
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data fordi dataene på sdb er enorme
vi vil vite hva er det beste alternativet 1 eller 2?
eller annen ide om å fikse filsystemfiksingen?
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 – hva er risikoen når du gjør fsck på enorme data?
Kommentarer
Svar
Sitat dette SuperUser-innlegget :
fscker bare det opprinnelige navnet. Når de kom ut med nye filsystemer, trengte de et spesifikt verktøy for hver,efsckfor ext,e2fsckfor ext2,dosfsck,fsckvfat. Så de lagdefsckfrontenden som bare ringer det som er riktig verktøy.
fsck.xfs er sannsynligvis det du er ute etter.
XFS-relatert oppdatering:
xfs_check og xfs_repair skal hjelpe deg med å evaluere skaden og reparer om mulig.
Se manualsidene for spesifikk bruksinformasjon.
Kommentarer
- slik at vi kan være trygge når vi gjør det – fsck -y / dev / sdb?
- @yael Det avhenger, jeg personlig synes det er, men dette er sannsynligvis meningsbasert.
- så hva er bedre fsck .xfs -y / dev / sdb eller fsck -y / dev / sdb
- @yael Jeg tror begge vil gjøre den samme jobben. Men jeg pleier alltid å spesifisere typen, dvs. Jeg vil bruke
fsck.xfs. - så hva er forskjellen mellom xfs_repair og fsck.xfs?
Svar
Til de som stemmer på fsck.xfs … det er bare en omdøpt versjon av / bin / true. Det gjør ingenting bortsett fra å returnere «0» og avslutte Det riktige svaret er:
umount /data xfs_repair /dev/sdb mount /data Kommentarer
- Du vil legge merke til at xfs_repair ble nevnt i annet svar
e2fsckpå det?