Subject: Re: panic: ffs_alloccgblk: can't find blk in cyl
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 03/02/1996 08:22:45
> 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
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.)