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:

 fsdb /dev/ad1s1a
 ** /dev/ad1s1a
 Editing file system '/dev/ad1s1a'
 Last mounted on /mnt/ad1s1a
 [output omitted]
 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:
 ** /dev/da1s1a
 ** 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
 NAME=/dsj????
 REMOVE=YES
 ** 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
 ADJUST? yes
 ** Phase 5 - Check Cyl groups
 FREE BLK COUNT(S) WRONG IN SUPERBLK
 SALVAGE? yes
 SUMMARY INFORMATION BAD
 SAVLAGE? yes
 BLK(S) MISSING IN BIT MAPS
 SALVAGE? yes
 60039 files, 464655 used, 423188 free (43248 frags, 47492 blocks, 4.9% fragmentation)
  FILE SYSTEM MARKED CLEAN 
  FILE SYSTEM WAS MODIFIED 

 This is it?
 Basically yes.
 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 | 175 views