From owner-freebsd-hackers Sun Feb 9 11:21:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01620 for hackers-outgoing; Sun, 9 Feb 1997 11:21:08 -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 LAA01611 for ; Sun, 9 Feb 1997 11:20:58 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09021; Sun, 9 Feb 1997 14:20:24 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun, 9 Feb 1997 14: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 NAA01090 for ; Sun, 9 Feb 1997 13:15:55 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id NAA23758 for freebsd-hackers@freefall.cdrom.com; Sun, 9 Feb 1997 13:20:18 -0500 (EST) Date: Sun, 9 Feb 1997 13:20:18 -0500 (EST) From: Thomas David Rivers Message-Id: <199702091820.NAA23758@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > > As Thomas David Rivers wrote: > > > Another interesting item I've discovered is that the fs->cgmask is > > 0xffffffff, rendering most of the macro below unused... here's the logic > > I've evaluated. These macros are in /sys/ufs/ffs/fs.h: > > > Now - here's a strangeness - fs->cgmask (as evidenced by my printf()s), > > is 0xfffffff, the logical compliment of that is 0; giving: > > > > (fs->fs_fpg) + fs->fs_iblkno; > > Bingo! > > You can also see this on any actual filesystem by using dumpfs. If > you look into newfs's mkfs.c, you'll notice that there's ``no such > thing like a filesystem with only one track (head)'' in newfs' > opinion. This causes the 0xffffffff cgmask calculation, since our > newfs basically creates only filesystems with 1 track (heads) and 4096 > sectors per track, unless directed otherwise. > > I've hacked up my /sbin/newfs to fake 2 tracks in my personal mfs > case, and i was immediately able to beat the hell out of it. > Previously, this mfs on my (diskless booting) scratchbox was fragile > like a FreeBSD coffee-mug. Right now, i was able to compile inside > the mfs, extract huge tar files, run big cmp(1) jobs (which includes > mmapping), run it ouf of i-nodes, run it out of space. Well, sorta > for the latter, but only since the machine ran out of swap before the > mfs filled up. Yet, it didn't panic with bad dirs, mangled entries > etc. like it used to do before whenever doing ``something serious'' in > the mfs. > > So either something is wrong with the filesystem code here, or it > simply couldn't grok a filesystem with only one head. As a stop-gap > measure, i suggest we bump the 1*4096 faked number in newfs to 2*2048. > ... Let me just echo back what you're saying, so I'm sure I have a clear understanding: You're saying the code in newfs.c that sets NTRACKS to 1 and NSECTORS to 4096 would be changed. The comment there: /* * About the same time as the above, we knew what went where on the disks. * no longer so, so kill the code which finds the different platters too... * We do this by saying one head, with a lot of sectors on it. * The number of sectors are used to determine the size of a cyl-group. * Kirk suggested one or two meg per "cylinder" so we say two. */ The value of 1 causes the fs_cgmask to be set to 0xffffff, as it is computed by: for (sblock.fs_cgmask = 0xffffffff, i = sblock.fs_ntrak; i > 1; i >>= 1) sblock.fs_cgmask <<= 1; making it unused in the disk block calculation. 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?) What I'm getting at, and I'm willing to believe it; is that we are very lucky that the file system works at all, if we're calculating block offsets incorrectly. I'll try a new version of newfs and report back. - Dave Rivers - --NAA23741.855512336/lakes.water.net--