From owner-freebsd-fs@FreeBSD.ORG Wed Feb 1 06:26:49 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA0C106566B; Wed, 1 Feb 2012 06:26:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id D915F8FC13; Wed, 1 Feb 2012 06:26:48 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q116Qhvf060616; Tue, 31 Jan 2012 22:26:44 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201202010626.q116Qhvf060616@chez.mckusick.com> To: eugene@zhegan.in In-reply-to: <201201300540.q0U5eDYi068367@freefall.freebsd.org> Date: Tue, 31 Jan 2012 22:26:43 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:26:49 -0000 > From: Kostik Belousov > To: bug-followup@FreeBSD.org, eugene@zhegan.in > Cc: > Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency > Date: Mon, 30 Jan 2012 07:30:04 +0200 > > You failed to mention which panic you got. Was it 'dup alloc' ? A > backtace would be also useful. > > If it was indeed 'dup alloc', then there is nothing fsck or snapshots > can be accused for. Your filesystem is in inconsistent state, which > requires full fsck to recover. It must be not mounted while not > repaired. > > Somewhat more interesting is how the fs got into this state. Thanks for your report and in particular a small file image that demonstrates the problem. I have been able to reproduce your panic reliably on my test machine. Running a normal fsck on the image does indeed show that the filesystem has corruption that is unexpected on a filesystem running with soft updates. So, in the end, if the background fsck were able to run, it would fail and notify the system that it needed to be checked by a full fsck. But as you have aptly demonstrated, the background fsck crashes the system as it tries to take a snapshot of the filesystem on which to run its check. The cause of the crash is because in taking a snapshot, the filesystem needs to allocate an inode for the snapshot. As it turns out, the inode that it tries to allocate is marked free in the inode map, but is in fact already allocated which leads to the panic. I am still mulling over how to resolve this problem, but have not yet come up with one. I am looking for a solution that effectively will let the snapshot fail rather than crashing the system so that the fsck -B can then gracefully fail and lead to the full fsck as is needed in this case. Kirk McKusick