Date: Tue, 12 Apr 2016 13:05:50 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 208691] "panic: ffs_valloc: dup alloc" as soon as UFS root partition is mounted Message-ID: <bug-208691-3630-zZKZt9AWOB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-208691-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-208691-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208691 --- Comment #2 from Martin Guy <martinwguy@gmail.com> --- Thanks Kirk, that made the system boot again. Unfortunately the interesting parts of the fsck output scrolled off the screen before I could copy them, = so I don't know what the filesystem defect was that provoked this panic. However, if the same thing happens to a distant server with only a console,= it would panic while mounting / to go into single-user mode too, making the sy= stem unrecoverable. Peter H wrote to say: > the first (journaled) fsck just replays the journal; it does not > check the file system. That is why journaling fsck is so fast. So another way of seeing the problem is that, if "fsck -p" fails, it tells = the user to run "fsck -y" which says "yes" to fsck's initial "USE JOURNAL?" question and this results in a faster check that doesn't fix the kernel-panicking inconsistency. It needs -fy to get round the "USE JOURNAL?" option. Another solution could be to always do a full check without the journal whe= n a fast filesystem is not clean, instead of "-p"? I don't see a combination of fsck flags to do that. -fyC looks like the closest but needs changing to ma= ke -C override -f and skip the check if the filesystem is clean. Or turning write-behind off by default until a better fix is found? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-208691-3630-zZKZt9AWOB>