Date: Sun, 9 Feb 1997 13:20:18 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Message-ID: <199702091820.NAA23758@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702091820.NAA23758>