Let’s assume the system panics again with the same error message.
If you were lucky enough you even saw which directory was last accessed before the panic.
This may be valuable to know if you run some certain type of application and could reveal yet unknown application errors or even vulnerabilities like temporary file creation race conditions.
/mnt/da1s1a: bad dir ino 16392 AT OFFSET 512: MANGLED ENTRY
panic: ufs_dirbad: bad dir
So you now have proof that there is (still) an unfixed corruption on the file system.
You also have proof that it happened at the same inode than before.
If it’s not the same inode, then you know for sure that there’s either another corruption or faulty hardware which causes excessive errors.
For the latter case remember what I wrote before about faulty hardware.
Right, now how to fix it?
To fix it go back to single user mode and re-run fsck just to make sure. Keep your device mounted read-only.
Then start the file system debugger, fsdb:
Editing file system '/dev/ad1s1a'
Last mounted on /mnt/ad1s1a
fsdb (inum: 2)>
Now go to the inode which was mentioned during kernel panic to get some additional information.
fsdb (inum: 2)> inode 16392
current inode: directory
I=16392 MODE=40755 SIZE=512
BTIME=Oct 23 11:47:24 2006 [0 nsec]
MTIME=Oct 23 11:47:24 2006 [0 nsec]
CTIME=Oct 23 11:47:24 2006 [0 nsec]
ATIME=Oct 23 11:47:24 2006 [0 nsec]
OWNER=root GRP=WHEEL LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=157338b7
fsdb (inum: 16392)>
Even if it results in data loss, clearing the inode is the way to go to get rid of this.
fsdb (inum: 16392)> clri 16392
Then exit the debugger:
fsdb (inum: 16392)> 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
Run fsck as told:
** Last Mounted on /mnt/da1s1a
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED I=16392 OWNER=root MODE=0
SIZE=512 MTIME Oct 23 11:47:24 2006
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counters
LINK COUNT DIR I=2 OWNER=root MODE=40755
SIZE=512 MTIME=Oct 23 11:47:24 2006 COUNT 21 SHOULD BE 20
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SUMMARY INFORMATION BAD
BLK(S) MISSING IN BIT MAPS
60039 files, 464655 used, 423188 free (43248 frags, 47492 blocks, 4.9% fragmentation)
FILE SYSTEM MARKED CLEAN
FILE SYSTEM WAS MODIFIED
This is it?
However I recommend rebooting the system once more into single user mode to rerun ‘find’.
This will reveal if there is (no) further corruption. Also the reboot will ensure that the operating system can re-read the disklabel and file system properly. This is especially important after messing around with the file system debugger.
For this reason do run fsck once more just to make sure the file system is really clean.
Also try keeping to these premises:
one corruption may happen once in a while and really mean nothing
two is still possible but must be looked at critically
three is a bad sign, there’s usually more to come
Remember: The file system is at the heart of your server. Messing it up could compromise your data, your users and even your job. So care for it!
SOurce : https://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/comment-page-1/
Posted on: April 29, 2021,
by : Julian's
| 108 views