Musimy naprawić uszkodzenie systemu plików na sdb w wersji redhat 6
sdb to system plików xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data ponieważ dane na sdb są ogromne
chcemy wiedzieć jaka jest najlepsza opcja 1 czy 2?
czy inny pomysł na naprawę systemu plików?
opcja 1
umount /data fsck -y /dev/sdb mount /data opcja 2
umount /data e2fsck -y /dev/sdb mount /data opcja 3
umount /data xfs_repair /dev/sdb mount /data Po drugie – jakie są zagrożenia podczas wykonywania fsck na ogromnych danych?
Komentarze
Odpowiedź
Cytując ten post SuperUser :
fsckto tylko oryginalna nazwa. Kiedy pojawili się z nowymi systemami plików, potrzebowaliby specjalnego narzędzia dla każdego z nich,efsckdla ext,e2fsckdla ext2,dosfsck,fsckvfat. Dlatego stworzylifsckinterfejs, który po prostu wywołuje odpowiednie narzędzie.
fsck.xfs to prawdopodobnie to, czego szukasz.
Aktualizacja związana z XFS:
xfs_check i xfs_repair powinny pomóc w ocenie szkód i napraw, jeśli to możliwe.
Zobacz strony podręcznika, aby uzyskać szczegółowe informacje dotyczące użytkowania.
Komentarze
- abyśmy byli bezpieczni kiedy robimy – fsck -y / dev / sdb?
- @yael To zależy, osobiście uważam, że tak jest, ale jest to prawdopodobnie oparte na opiniach.
- więc co jest lepsze fsck .xfs -y / dev / sdb lub fsck -y / dev / sdb
- @yael Myślę, że oba będą wykonywać to samo zadanie. Ale zawsze określam typ, tj. Użyłbym
fsck.xfs. - Więc jaka jest różnica między xfs_repair a fsck.xfs?
Odpowiedz
Do osób głosujących na fsck.xfs … to tylko zmieniona nazwa / bin / true. Nie robi nic poza zwracaniem „0” i zamykaniem . Prawidłowa odpowiedź to:
umount /data xfs_repair /dev/sdb mount /data Komentarze
- Zauważysz, że xfs_repair zostało wspomniane w inna odpowiedź
e2fsck?