> > Time <-> space tradeoff...
> 
> I agree totally with your comment of "meaningless parameters!" These
> optimizations were great when they were implimented, but things have
> changed. But, digressing, couldn't the last cylinder group just not be full?
> Or could we come up with a dead_blocks file, which ffs and fsck_ffs know
> not to touch, and "put" the nonexistant areas in there? I'm not that
> familiar w/ ffs, so the question's a bit simplistic. :-)

On machines like the '030 Macintoshes I would rather lose a few 100K of
disk storage than much time in the fs code -- disk access is already
slow enough.

> > Do they? An OS has to know its disks _somehow_, hasn't it?
> 
> Hmm. I think I was wrong above. But the idea is that I don't know if all
> systems keep the magic flags in the first bytes of the disk. We could,
> in principle, run into a (pathalogical) case where a partition map on
> disk passes two different ID tests. True, if there's a CRC on the label,
> I bet only one will pass, but if the ID is just a magic flag, we might
> have a problem.

You would usually want to keep your 1st level boot code and the
partition table in the first few disk blocks because they are the only
place on a {SCSI,ESDI,ST506,whatever} disk that can be accessed without
any geometry information. So you're pretty safe here.

        hauke

-- 
"It's never straight up and down"  (DEVO)