From owner-freebsd-hackers Thu Feb 11 07:32:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02552 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 07:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02545 for ; Thu, 11 Feb 1999 07:32:37 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id HAA29608; Thu, 11 Feb 1999 07:30:24 -0800 (PST) Message-Id: <199902111530.HAA29608@implode.root.com> To: mjacob@feral.com cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-reply-to: Your message of "Thu, 11 Feb 1999 07:01:17 PST." From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Feb 1999 07:30:23 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Really? I found it fairly easy to reproduce in that every time I had a >large filesystem (e.g. > 10GB) and ran some fairly simple tests that >exercise VM and Filesystem interactions (simple code available on request- >NetBSD and FreeBSD fail in interesting and uninteresting ways. Solaris and >Linux pass unless there's an underlying h/w problem). I stopped testing >when I wasn't getting any response on this (see below for why)- but if >somebody is thinking of attacking this problem again I can certainly do >some testing (I may not be able to make test systems directly available >because of some NASA policies but I can probably snag some systems for >myself to run tests with- I have a couple of FreeBSD systems running >NASA/Ames still plus the ones I have at Feral (although Feral's disk >resources are substantially *less* than NASA/Ames!)). > >Here's a couple of private emails that listed problems I was seeing. It >really seems to live down in the realloc blocks code. I wasn't subscribed >to freebsd-hackers back then, so I probably just didn't get this problem >announced to the right group. ... >++panic: ffs_reallocblks: unallocated block 1 >++ >++ >++With a stack of: >++ ffs_reallocblks >++ cluster_write >++ ffs_write >++ vn_write >++ write I thought it was made fairly clear that there were problems with missing bmap operations in some places, which are brought to the surface with the reallocblks code. I also thought it was made fairly clear that there is a sysctl variable available to disable reallocblks (vfs.ffs.doreallocblks). I know I've sent many messages on this subject to the FreeBSD lists; I apologize if you didn't see them. In any case, the reallocblks problems are believed to be fixed now. If this isn't true, then we need to make sure that it is set to disabled for the upcoming 3.1 release. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message