Date: Mon, 10 Feb 1997 07:50:29 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!critter.dk.tfs.com!phk Cc: ponds!root.com!dg, ponds!freebsd.org!hackers, ponds!freebsd.org!joerg Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Message-ID: <199702101250.HAA26033@lakes.water.net>
index | next in thread | raw e-mail
Poul-Henning Kamp
>
> In message <199702091853.NAA24339@lakes.water.net>, Thomas David Rivers writes:
> >
> >I built a new "newfs", with NTRACKS bumped to 2 and NSECTORS dropped
> >to 2048.
> >
> >It worked like a champ! No more panic: ffs_valloc: dup alloc.
> >
> >I'd say the problem is that the underlying code can't handle one
> >track (head).
> >
> >We should probably go ahead and use this work-around in 2.1.7 and
> >2.2. Perhaps, if we're so inclined, we can determine what a
> >better fix would be to keep the 1 track idea. [It could possibly
> >be simply setting fs->fs_cgmask to 0 if the number of tracks is 1; but
> >I'm not sure.] That investigation could wait until after 2.2 and
> >2.1.7.
>
> I've looked at the code, and I cannot see how it could be because
> of fs_cgmask being 0xffffffff.
>
> There must be some other explanation.
>
> Do you have the first couple of hundred lines from a dumpfs on the
> filesystem (when made with heads=1 ?)
>
I'll try getting it with a fixit floppy.
But, if you'll read my previous writeup; you'll see that a fs_cgmask
of 0xffffffff causes a problem in the cgstart macro:
#define cgstart(fs, c) \
(cgbase(fs, c) + (fs)->fs_cgoffset * ((c) & ~((fs)->fs_cgmask)))
effectively eliminating the fs_cgoffset value. This is what we're
guessing is the problem.
> --
> Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team.
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702101250.HAA26033>