meg kell javítanunk a fájlrendszer sérüléseit az sdb-n a redhat 6 verzión
sdb az xfs fájlrendszer
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data mivel az sdb-n óriási az adat
szeretnénk tudni mi a legjobb 1. vagy 2. lehetőség?
vagy más ötlet a fájlrendszer javításának elvégzésére?
1. opció
umount /data fsck -y /dev/sdb mount /data 2. lehetőség
umount /data e2fsck -y /dev/sdb mount /data 3. lehetőség
umount /data xfs_repair /dev/sdb mount /data második – milyen kockázatokkal jár az fsck használata hatalmas adatokon?
Megjegyzések
Válasz
a SuperUser bejegyzés idézése :
fsckcsak az eredeti név. Amikor új fájlrendszerekkel jelentkeztek, mindegyikükhöz külön eszközre lesz szükségük,efsckaz ext-re,e2fsckaz ext2-re,dosfsck,fsckvfat. Tehát készítették azfsckkezelőfelületet, amely csak a megfelelő eszközt hívja.
fsck.xfs valószínűleg ezt követi.
Az XFS-hez kapcsolódó frissítés:
xfs_check és xfs_repair segítenek a károk értékelésében és ha lehetséges, javítsa ki.
Az egyes használati információkat a kézikönyv oldalain találja.
Megjegyzések
- hogy biztonságban lehessünk amikor megtesszük – fsck -y / dev / sdb?
- @yael Ez attól függ, én személy szerint azt gondolom, de ez valószínűleg véleményalapú.
- akkor mi a jobb az fsck .xfs -y / dev / sdb vagy fsck -y / dev / sdb
- @yael szerintem mindkettő ugyanazt a munkát végezné. De hajlamos vagyok mindig megadni a típust, pl. A következőt használnám:
fsck.xfs. - tehát mi a különbség az xfs_repair és az fsck.xfs között?
Válasz
Az fsck.xfs-re szavazó embereknek … ez csak a / bin / true átnevezett változata. Nem tesz mást, csak adja vissza a “0” -t és lépjen ki . A helyes válasz:
umount /data xfs_repair /dev/sdb mount /data Megjegyzések
- Észre fogja venni, hogy az xfs_repair említésre került a a másik válasz
e2fsckfájlt?