From owner-freebsd-bugs@FreeBSD.ORG Fri Dec 30 18:10:14 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED8CC16A422 for ; Fri, 30 Dec 2005 18:10:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7D943D5A for ; Fri, 30 Dec 2005 18:10:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBUIAEmd098118 for ; Fri, 30 Dec 2005 18:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBUIAECi098117; Fri, 30 Dec 2005 18:10:14 GMT (envelope-from gnats) Date: Fri, 30 Dec 2005 18:10:14 GMT Message-Id: <200512301810.jBUIAECi098117@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: David Kirchner Cc: Subject: Re: i386/84589: 5.4-STABLE unresponsive during background fsck 2TB partition X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Kirchner List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 18:10:15 -0000 The following reply was made to PR kern/84589; it has been noted by GNATS. From: David Kirchner To: bug-followup@freebsd.org Cc: Subject: Re: i386/84589: 5.4-STABLE unresponsive during background fsck 2TB partition Date: Fri, 30 Dec 2005 10:07:28 -0800 This bug has been reproduced on a different server (similar hardware) running 6.0-RELEASE and UFS2. I accidentally forgot to disable background fscks on the server (big d'oh!) and about 12 hours after the server rebooted access to the disk started slowing down, eventually becoming completely unresponsive, forcing a reboot. The reboot took about 2 minutes to take effect, probably because the server was "busy" with the fsck. I was able to log in to it before it locked up, and tried ktrace'ing the fsck_ffs process. It had no activity. I suspect it deadlocked against something else. Unfortunately the server was a NFS server, so the NFS client also had to be rebooted due to a separate NFS client deadlock bug. The how-to-repeat is the same: That ^C fsck step is just to trigger a dirty filesystem. Really, really easy to duplicate. The workaround is the same: Disable background_fsck for all 5.4 or 6.0 servers (or for any servers capable of performing a background fsck). FWIW: The foreground fsck takes far less than 12 hours to complete.