From owner-freebsd-hackers  Mon Feb 10 05:20:47 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA01952
          for hackers-outgoing; Mon, 10 Feb 1997 05:20:47 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA01942
          for <freebsd-hackers@freebsd.org>; Mon, 10 Feb 1997 05:20:41 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA24673; Mon, 10 Feb 1997 08:20:04 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 10 Feb 1997 08:20 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id HAA29942; Mon, 10 Feb 1997 07:35:56 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id HAA25989; Mon, 10 Feb 1997 07:40:22 -0500 (EST)
Date: Mon, 10 Feb 1997 07:40:22 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199702101240.HAA25989@lakes.water.net>
To: ponds!uriah.heep.sax.de!joerg_wunsch, ponds!whistle.com!julian
Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS???
Cc: ponds!freebsd.org!freebsd-hackers, ponds!lakes.water.net!rivers
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Julian Elischer wrote:
> 
> J Wunsch wrote:
> > 
> > As Thomas David Rivers wrote:
> > 
> > >  You're saying the code in newfs.c that sets NTRACKS to 1 and
> > > NSECTORS to 4096 would be changed.
> > 
> > Yes, to e.g. 2 * 2048 instead.  It's a mileage number only anyway,
> > since Poul found out (experimentally) that it just works better than
> > any (un)real number on today's zone-bit recorded and large cache
> > disks.
> > 
> > >  If this is so, doesn't that mean that everyone is using a file system
> > > that is questionable.  Aren't inode reads/writes going to the wrong
> > > places (albeit consistently?)
> > 
> > I'm no filesystem expert at all, but this seems to be the case.  The
> > failure picture matches consistently with the reported MFS troubles
> > (including mine), and it's probably also responsible for some other
> > panic PRs you could find in the GNATS database.
> > 
> > --
> >
> Kirk suggested setting the number of heads to 1 to
> turn off the "selelct a nearby head" code..
> 
> if you make it have 2 heads, this code will be enabled
> again and we'll lose the effect..
> it pessimise the accesses by switching to a differnt head that it 
> thinks has a nearby free block.. in the case of 2 heads (as suggested)
> this is actually likely to be "NOT NEARBY" and we will lose
> 
> you could HEAR the difference when we went to 1 head..
> 
> 

 Hmmm... well, that's certainly not the best news.  But I would
assert that the file system isn't working properly without this problem
corrected.

 An alternative I was considering was to set the file system's fs_cgmask
to 0 if the number of tracks is 1.  (Instead of it's current,
problematic 0xffffffff).   But, it's just a guess from my point of
view; I'm no filesystem expert.

 I'll try that out and report back.

 If that works, then we can return to having NTRACKS be 1.

	- Dave Rivers -