Delete a directory, crash the system
Benjamin Kaduk
kaduk at MIT.EDU
Mon Mar 23 14:55:18 UTC 2015
On Mon, 23 Mar 2015, Da Rock wrote:
> On 27/07/2013 22:58, David Noel wrote:
> > > Post the stack trace of the core and maybe someone can help you.
> > panic: ufs_dirrem: Bad link count 2 on parent
> > cpuid = 0
> > KDB: stack backtrace:
> > #0 0xffffffff808680fe at kdb_backtrace+0x5e
> > #1 0xffffffff80832cb7 at panic+0x187
> > #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3
> > #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34
> > #4 0xffffffff808ca32a at kern_rmdirat+0x21a
> > #5 0xffffffff80b17cf0 at amd64_syscall+0x450
> > #6 0xffffffff80b03427 at Xfast_syscall+0xf7
> I know this is an old one, but I'm running 10 and I'm still getting this
> problem.
>
> kernel: panic: ufs_dirrem: Bad link count 2 on parent
> kernel: cpuid = 1
> kernel: KDB: stack backtrace:
> kernel: #0 0xffffffff808e7e90 at kdb_backtrace+0x60
> kernel: #1 0xffffffff808af975 at panic+0x155
> kernel: #2 0xffffffff80afe7d7 at ufs_rmdir+0x1d7
> kernel: #3 0xffffffff80d994f8 at VOP_RMDIR_APV+0x98
> kernel: #4 0xffffffff80952a68 at kern_rmdirat+0x1b8
> kernel: #5 0xffffffff80c8f127 at amd64_syscall+0x357
> kernel: #6 0xffffffff80c7581b at Xfast_syscall+0xfb
> kernel: Uptime: 2h36m59s
>
> Is there a fix or one in the works at all? This also not the first time I've
> had this issue crop up since I've been running 10. I am using ssd hdds if that
> helps.
I don't think there can be a fix in the works until the problem is
understood. Given the present data (i.e., lack of other reports), the
most likely explanation seems to be that your filesystem is corrupt or
your SSD is buggy. A full foreground fsck may be helpful at detecting
latent corruption, though.
-Ben Kaduk
More information about the freebsd-fs
mailing list