i386/84589: 5.4-STABLE unresponsive during background fsck 2TB
partition
David Kirchner
dpk at dpk.net
Fri Dec 30 10:10:15 PST 2005
The following reply was made to PR kern/84589; it has been noted by GNATS.
From: David Kirchner <dpk at dpk.net>
To: bug-followup at 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.
More information about the freebsd-bugs
mailing list