Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Feb 1999 07:30:23 -0800
From:      David Greenman <dg@root.com>
To:        mjacob@feral.com
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: softupdates 
Message-ID:  <199902111530.HAA29608@implode.root.com>
In-Reply-To: Your message of "Thu, 11 Feb 1999 07:01:17 PST." <Pine.LNX.4.04.9902110650060.13093-100000@feral-gw> 

next in thread | previous in thread | raw e-mail | index | archive | help
>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902111530.HAA29608>