> pos = 0, i = 13, fs = /space
> panic: ffs_alloccgblk: can't find blk in cyl

> [but fsck doesn't mind]  It shouldn't be possible for a filesystem to
> pass fsck and then provoke a kernel panic.

So there's a bug in fsck, the kernel, or both.

mycroft pointed out, quite correctly,

> You didn't give any indication of what kernel or fsck(8) version
> you're using.

Everything built from sources gotten via -current sup, started about
08:30 Feb 27 1996, Canada/Eastern timezone.

But I think the problem is likely very old, because this is _exactly_
the symptom (panic: ffs_alloccgblk: can't find blk in cyl) that I saw
when I tried to use fsresize on SunOS 4.1.2, and there too, fsck passed
the filesystem.  So there is probably a very longstanding bug in the
Berkeley ffs code, old enough that it's shared by SunOS 4.1.2 and
NetBSD-current.

A pretty damn subtle bug, too, since it's never bitten people in live
use before...or at least not enough to make anyone figure it out.

As I said, I'm investigating.  But I don't really understand this
"rotational position" stuff enough.  If I can repeat it with
filesystems that compress down decently small, I'll send-pr it and
either include a guilty filesystem or offer to send it to anyone who
wants it.  The filesystem I actually had it happen with was

Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
/dev/sd0f        884501   470296   369979    56%    /space

which is not something I want to casually drop into a PR. :-)
(Besides, that particular filesystem has security-sensitive information
on it, so I don't want to give it out at all.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu