panic: ufs_dirbad i restarty freeBSD

This page was exported from - Adam Kucza
Export date: Thu Mar 2 23:15:23 2017 / +0000 GMT
panic: ufs_dirbad i restarty freeBSD
Dobry administrator zawsze i dok?adnie czyta logi, z akcentem na dok?adnie :).
Kilka dni temu mia?em do?? ciekawy przypadek automatycznego restartu serwera na skutek wykonywania prostych polece?, np.
find lub locate.
Co ciekawsze, serwer "wywala?" si? zawsze na tym samym katalogu. Z pocz?tku my?la?em, ?e to wina us?ugi samba i
udost?pnionych plików/katalogów, jednak po wnikliwym wczytaniu si? w logi systemowe, przekona?em si?, ?e by?em w b??dzie.
B??d by? widoczny ju? w samym dmesg (logi systemowe)
/dev/ad0s1: bad dir usr 25789343 AT OFFSET 1024: MANGLED ENTRY
panic: ufs_dirbad: bad dir
Z tego wynika, ?e mamy do czynienia z wadliwym katalogiem usr.
Niby prosta rzecz, wchodzimy do single user mode (wtedy dyski/partycje nie s? zamontowane).
Sprawdzamy tzw. mount point poleceniem
cat /etc/fstab
i traktujemy zamontowan? etykietk? (label) jako katalog /usr poleceniem fsck
# fsck -y /dev/ad0s1f
(u mnie /usr jest zamontowany jako ad0s1f).
Na koniec skanowania powinno nam si? wy?wietli?
***** FILE SYSTEM MARKED CLEAN *****
Po ponownym uruchomieniu serwera sprawdzamy czy wszystko jest OK przyk?adowymi poleceniami
# find / -type d -exec ls -ld {} ;
# find / -type d -exec stat {} ;
# find / -type d -exec touch {}/mydummyfilenamewhichshouldnotexist ;
Najwyra?niej fsck nie poradzi?o sobie z tym dziwnym przypadkiem, poniewa? freeBSD nadal si? restartuje (panic) podczas
wykonywania powy?szych testów.
Na szcz??cie jest sposób aby to naprawi?, ale mo?e wyst?pi? sytuacja, ?e z uszkodzonego katalogu nie odzyskamy danych,
aczkolwiek b?d?my dobrej my?li i miejmy pewno??, ?e mamy zrobion? wcze?niej kopi? zapasow? tych danych. Istot? rozwi?zania
problemu jest naprawienie systemu plików i wyeliminowanie samoistnych restartów systemu freeBSD.
B?d?c ponownie w trybie single user mode uruchamiamy narz?dzie fsdb (FileSystem DeBugger)
# fsdb /dev/ad0s1f
** /dev/ad0s1f
Editing file system '/dev/ad0s1f'
Last mounted on /mnt/ad0s1f
(...)
fsdb (inum: 2)>
Output as PDF file has been powered by [ Universal Post Manager ] plugin from www.ProfProjects.com
| Page 1/3 |
This page was exported from - Adam Kucza
Export date: Thu Mar 2 23:15:23 2017 / +0000 GMT
Teraz wpisujemy numer tzw. inode, który bierzemy z loga (u mnie by? to numer 25789343)
fsdb (inum: 2)> inode 25789343
current inode: directory
I= 25789343 MODE=40777 SIZE=1024
BTIME=May 9 12:52:12 2008 [0 nsec]
MTIME=May 9 12:52:12 2008 [0 nsec]
CTIME=May 9 12:52:12 2008 [0 nsec]
ATIME=May 9 12:52:12 2008 [0 nsec]
OWNER=root GRP=WHEEL LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=157338b7
fsdb (inum: 25789343)>
Nawet gdy stracimy dane, b?dziemy mieli pewno??, ?e problem zostanie usuni?ty.
Poleceniem clri debuguj?c inode'a oznaczamy go jako b??dny
fsdb (inum: 25789343)> clri 25789343
Wychodzimy z narz?dzia debugowania.
fsdb (inum: 25789343)> quit
**** FILE SYSTEM STILL DIRTY *****
*** FILE SYSTEM MARKED DIRTY
*** BE SURE TO RUN FSDK TO CLEAN UP ANY DAMAGE
*** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload
B?d?c nadal w single user mode uruchamiamy ponownie fsck
# fsck -y /dev/ad0s1f
** /dev/ad0s1f
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED I= 25789343 OWNER=root MODE=0
SIZE=1024 MTIME May 9 12:52:12 2008
NAME=/_new2????
REMOVE=YES
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counters
(...)
Podczas skanowania pojawia?y si? jeszcze inne ró?ne b??dy, które naprawia?y si? automatycznie dzi?ki parametrowi -y, np.
LINK COUNT DIR I=2 OWNER=root MODE=40777
Output as PDF file has been powered by [ Universal Post Manager ] plugin from www.ProfProjects.com
| Page 2/3 |
This page was exported from - Adam Kucza
Export date: Thu Mar 2 23:15:23 2017 / +0000 GMT
SIZE=1024MTIME=May 9 12:52:12 2008 COUNT 21 SHOULD BE 20
ADJUST? yes
(...)
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
(...)
SUMMARY INFORMATION BAD
SAVLAGE? yes
(...)
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
Na ko?cu pojawi? si? komunikat
***** FILE SYSTEM MARKED CLEAN *****
***** FILE SYSTEM WAS MODIFIED *****
Ale czy to wszystko? Zdecydowanie tak.
W moim przypadku by?o du?o szcz??cia i wszystkie dane by?y na swoim miejscu.
Po prostu fsck jakim? dziwnym trafem nie potrafi? poradzi? sobie z b??dnym inode o numerze 25789343.
Oczywi?cie ponownie przetestowa?em find'em czy przypadkiem co? jeszcze nie zosta?o do naprawienia. Tym razem wszystko by?o
jak nale?y.
Jednak gdyby nadal by?y restarty typu panic: ufs_dirbad: bad dir, proponuj? powy?sze czynno?ci powtórzy? dla ka?dego z?ego
inode'a.
Pozdrawiam
Output as PDF file has been powered by [ Universal Post Manager ] plugin from www.ProfProjects.com
| Page 3/3 |