Date: Fri, 15 Nov 1996 21:43:35 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: Another possible explanation about my daily panics... Message-ID: <199611160243.VAA24034@lakes.water.net>
next in thread | raw e-mail | index | archive | help
I've been staring at/reading through ffs_valloc.c and think I might
have a potential explanation about the daily panics...
In ffs_nodealloccg(), we look for an free inode. When one is
found; the cg_inosused() bit is set "allocating" it.
However; if you look at the for() loop (just before the "gotit"
label) you'll see it marches "ipref" up as it looks for a free
inode.
But - and here's the crux of this - that calculated "ipref"
value does not take into account fs_ipg (inodes per group).
All the other calculations that set the allocated bit do
take into account fs->fs_ipg.
For the sake of this scenario, let's assume that this
calulated ipref is larger than fs->fs_ipg
(i.e. ipref != ipref & fs->fs_ipg). We set the wrong
bit in the bitstring; and more importantly, we don't set the
right bit...
Now, in ffs_vfree(), we redetermine the index to check the
allocated bit again - *but* when doing that we do account
for fs->fs_ipg... so, the bit we check isn't the one we
set.
This would seem to be quite consistent with the panic's I'm
seeing...
What do you think?
I'm going to put a new panic message in ffs_nodealloccg()
just after the "gotit:" label:
if(ipref != (ipref % fs->fs_ipg)) {
panic("ffs_nodealloccg: ipref != ipref & fs->fs_ipg\n");
}
If I trip over that one - I think I may have this figured out...
- Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611160243.VAA24034>