Project

General

Profile

Actions
Copy link

Bug #5592

closed

fsck sometimes fails to repair filesystem automatically, resulting in Panic: ufs_dirbad bad dir ino ... mangled entry

Added by Chris Buechler about 9 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
Operating System
Target version:
-
Start date:
12/04/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:

Description

On occasion, fsck returns clean on a filesystem that isn't actually clean, and mount kernel panics when attempting to mount it with something like the following.

Dump header from device /dev/label/swap0
  Architecture: amd64
  Architecture Version: 1
  Dump Length: 65536B (0 MB)
  Blocksize: 512
  Dumptime: Wed Dec  2 13:06:30 2015
  Hostname: 
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 10.1-RELEASE-p13 #0 c77d1b2(releng/10.1)-dirty: Tue Jun 23 17:00:47 CDT 2015
    root@pfs22-amd64-builder:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10
  Panic String: ufs_dirbad: /: bad dir ino 25601664 at offset 512: mangled entry
  Dump Parity: 3767607360

db:0:kdb.enter.default>  bt
Tracing pid 22 tid 100076 td 0xfffff8000451e920
kdb_enter() at kdb_enter+0x3e/frame 0xfffffe0043daf4b0
panic() at panic+0x175/frame 0xfffffe0043daf530
ufs_lookup_ino() at ufs_lookup_ino+0xec2/frame 0xfffffe0043daf640
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xa1/frame 0xfffffe0043daf670
vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe0043daf6d0
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xa1/frame 0xfffffe0043daf700
lookup() at lookup+0x56c/frame 0xfffffe0043daf780
namei() at namei+0x4d4/frame 0xfffffe0043daf840
kern_statat_vnhook() at kern_statat_vnhook+0xae/frame 0xfffffe0043dafa00
sys_lstat() at sys_lstat+0x30/frame 0xfffffe0043dafaa0
amd64_syscall() at amd64_syscall+0x351/frame 0xfffffe0043dafbb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0043dafbb0
--- syscall (190, FreeBSD ELF64, sys_lstat), rip = 0x800e00a9a, rsp = 0x7fffffffe2a8, rbp = 0x7fffffffe620 ---

Full dump of that attached (via https://forum.pfsense.org/index.php?topic=103444.0).

Booting into single user and manually running fsck 3-4 times in a row and rebooting will usually fix it.

Files

Dump (1).txt (134 KB) Dump (1).txt Chris Buechler, 12/04/2015 01:27 AM
Actions
Copy link
 #1

Updated by Jim Thompson about 9 years ago

  • Priority changed from Normal to Low
Actions
Copy link
 #2

Updated by Julien REVERT almost 8 years ago

Is it fixe now in 2.3.3? Or we again need to run into single user mode in order to run the fsck command?

Actions
Copy link
 #3

Updated by Jim Pingle almost 8 years ago

There are fixes in 2.3.3 for fsck, see #6340

That is a potentially a different problem from this, however, but hopefully the fix in #6340 means this won't be relevant any longer, or at least not for most users.

Actions
Copy link
 #4

Updated by Jim Pingle almost 3 years ago

  • Status changed from Confirmed to Closed

Nothing we can really do for this. We have changed the default filesystem type to ZFS, and fsck is not relevant there. The other mitigation measures we have put in place for UFS have been doing a decent job for the most part, but there are still occasional edge cases that need manual intervention. The real fix here is to move from UFS to ZFS.

Actions
Copy link

Also available in: Atom PDF