Project

General

Profile

Actions

Bug #5592

open

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

Added by Chris Buechler almost 6 years ago. Updated almost 5 years ago.

Status:
Confirmed
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 #1

Updated by Jim Thompson almost 6 years ago

  • Priority changed from Normal to Low
Actions #2

Updated by Julien REVERT almost 5 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 #3

Updated by Jim Pingle almost 5 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

Also available in: Atom PDF