From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 01:10:57 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBC4D9EF for ; Tue, 24 Mar 2015 01:10:57 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 692DBC6E for ; Tue, 24 Mar 2015 01:10:56 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 81951620A6; Tue, 24 Mar 2015 11:10:46 +1000 (EST) Message-ID: <5510B995.8060307@herveybayaustralia.com.au> Date: Tue, 24 Mar 2015 11:10:45 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: Delete a directory, crash the system References: <551007DD.5020109@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 01:10:57 -0000 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 :)