Date: Sun, 9 Feb 1997 17:13:29 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Message-ID: <Mutt.19970209171329.j@uriah.heep.sax.de> In-Reply-To: <199702090226.VAA22081@lakes.water.net>; from Thomas David Rivers on Feb 8, 1997 21:26:35 -0500 References: <199702090226.VAA22081@lakes.water.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Speaking about newfs, i've got local patches that allow to mount an mfs ``from /dev/null'', so you can use it at all on a diskless machine where you don't have a useful and/or valid template filesystem to mount the mfs above. I've always held my horse back due to the mentioned panics, but now that it looks like a different problem, does anybody mind me committing them? Basically, the /tmp line in my diskless scratchbox looks like: /dev/null /tmp mfs rw,-s50000,-i50000,-f512,-b4096 0 0 (where the 50000 blocks is overkill since the machine has only 20 MB of NFS swap allowed). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970209171329.j>