From owner-freebsd-stable  Fri Mar 16  1:26:24 2001
Delivered-To: freebsd-stable@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP id D8EEA37B71A
	for <stable@FreeBSD.ORG>; Fri, 16 Mar 2001 01:26:20 -0800 (PST)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.2/8.9.3) id f2G9Q4D57263;
	Fri, 16 Mar 2001 01:26:04 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 16 Mar 2001 01:26:04 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200103160926.f2G9Q4D57263@earth.backplane.com>
To: Harald Schmalzbauer <Harald.Schmalzbauer@gmx.de>
Cc: stable@FreeBSD.ORG
Subject: Re: yet another vinum panic (was How to debug - find error?)
References:  <28718.984707028@www10.gmx.net>
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Ok.  First, don't worry about trying to get a kernel core, it probably
    won't help in this case.  We've been trying to find this particular bug
    for months with little success, and what core's we've gotten have been
    useless because the corruption is occuring long before the actual panic.

    Each little bit of information helps.  I consider ccd reliable, so I
    believe what is happening is that the use of the software raid system is
    creating a tiny bit of extra latency which is causing the bug 
    (elsewhere in the filesystem code) to rear its ugly head.  It gives me
    another area to research... I'll try running filesystem tests in a
    software RAID-1 configuration with ccd.

:Lots of small (500k)(~500.000) and a view bigger (10M)

    You can reduce your fsck time considerably if you are storing large
    files in the filesystem by reducing the number of inodes in the
    filesystem, increasing the block size, and increasing the number
    of cylinders per group.  I would recommend something like this:

	newfs -f 2048 -b 16384 -i 262144 -c 999 ....

    The only downside is that this will result in fewer inodes.  But
    if you only store larger (e.g. greater then 32K) files in the
    filesystem, you shouldn't run out.  See 'man newfs' for more
    information on the above options.  Note:  The fragment size
    (-f option) must always be 1/8 the block size (-b option), and I
    do not recommend using any block size other then 8192 (the default),
    or 16384 on a production system.

						-Matt

:>There are all sorts of possible sources to the problem unfortunately,
:>it may not be possible to easily diagnose it.   It could be the RAID,
:>NFS, a bug in the kernel, a bug in the network stack... just about
:...
:
:I don't think this is anything other related than to the IDE drives. The
:RAID was in operation for half a year without any error, the NFS-Mounts are the
:same I do for one year. This panic just occurs if I configure a software
:raid.
:Everything is working fine when I do the same tests to one of the IDE drives
:alone under the same circumstances.
:
:>The first thing I would do, if you haven't already, is upgrade to the
:>absolute latest FreeBSD-stable kernel.
:
:I cvusped today and built world today.
:
:Thank you,
:
:-Harry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message