Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Mar 2015 11:10:45 +1000
From:      Da Rock <freebsd-fs@herveybayaustralia.com.au>
To:        Benjamin Kaduk <kaduk@MIT.EDU>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Delete a directory, crash the system
Message-ID:  <5510B995.8060307@herveybayaustralia.com.au>
In-Reply-To: <alpine.GSO.1.10.1503231049050.22210@multics.mit.edu>
References:  <CAHAXwYDPMrdY-TP-5T1_6M_ot4gY09jo2_Wi_REOmE=%2Bu%2B_QuQ@mail.gmail.com> <CAGwOe2byRc4LVsyxvTJgxNGCbhvOEaeDXjmFJ7DoXThPQe1bcQ@mail.gmail.com> <CAHAXwYCj9AV8ZcDffNNGx-ivL=h_TK9zLQRTPknArX25HSfEag@mail.gmail.com> <CAGwOe2YCDRqHudovDB_Kz9WHppvB8v2L%2B0gkDnWgG88bgZTKSA@mail.gmail.com> <CAHAXwYCnRDQqgRcvaEE1BmSJYYOidoQzzUoHX_QWdyJzYO3kKw@mail.gmail.com> <551007DD.5020109@herveybayaustralia.com.au> <alpine.GSO.1.10.1503231049050.22210@multics.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 24/03/2015 00:50, Benjamin Kaduk wrote:
> 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
Unfortunately, fsck isn't helping - foreground or otherwise. All it 
shows on every single fs is inode 4 recovery which doesn't sound quite 
right. And again, it is only showing during updates to ports being 
built. I'm investigating further, but it may be just a corrupt file in 
pkg system.

Incidentally, I'm not suggesting an absolute fix for the issue as such, 
but a better means of handling it rather than crashing the system. The 
posts on this I've read have suggested as much, but it appears nothing 
is moving forward.

If I discover anything more I'll keep everyone posted :)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5510B995.8060307>