From owner-freebsd-fs Mon Feb 25 17:41:25 2002 Delivered-To: freebsd-fs@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 34C5437B404 for ; Mon, 25 Feb 2002 17:41:20 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id g1Q1f8i28365; Mon, 25 Feb 2002 17:41:08 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200202260141.g1Q1f8i28365@beastie.mckusick.com> To: Matthew Dillon , Ian Dowse Subject: Re: UFS panic on -stable Cc: Kris Kennaway , Tony Finch , fs@FreeBSD.ORG, fanf@chiark.greenend.org.uk In-Reply-To: Your message of "Mon, 25 Feb 2002 17:30:42 PST." <20020225173042.A62821@xor.obsecurity.org> Date: Mon, 25 Feb 2002 17:41:08 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The fact that this is happening on mfs which (presumably) is running async and without soft updates plus the fact that it is not doing any disk I/O should be a big help in tracking down this bug. It does point a big finger at the buffer cache code since that would be about the only place that data corruption could be happening here. Perhaps we can find a reliable way to generate a crash. Maybe a series of mknod/rm commands. If we can find a way to reliably get this panic, finding the bug should be possible. And if this is the elusive bitmap corruption panic we have been hunting for the last two years, that would really make my day! Kris, can you send the result of a `mount -v' command on your system so we can confirm that the mfs filesystems are running async without soft updates. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message