:But then, maybe I'm too much an HAMMER enthusiast, and we should go the
:Linux route and always install a (UFS) /boot. Then it is also easier to
:run more complex setups, like vinum, ccd, etc.
:
:cheers
: simon
I think you're more enthusiastic about a HAMMER-only install then I
am :-). To me, UFS1 is a perfectly fine filesystem... for small
partitions. There's no reason to throw it away.
The biggest problem I see with trying to put too much intelligence in
the boot code is simply that there is no way for it to keep up with
the kind of intelligence we can put into the kernel. It's a lot easier
to implement new and cool filesystem / mounting / vinum / etc features
with a full-fledged kernel running.
The partition naming scheme also looks a lot more natural if we make
'a' the small boot partition, leave 'b' as swap, and make 'd' the
root mount and rest of the disk (for a BOOT+HAMMER install). That way
swap space can stay on the much higher bandwidth outer rim of the disk
without us having to intentionally mis-order the partition offsets.
There are a few other things I'd like to get done for this release.
Sacha has kindly taken on adding a BOOT+HAMMER feature to the
installer. I will take on fixing up fdisk to handle multi-terrabyte
disks. Right now it wraps the 32 bit logical block length instead
of assigning the max value (0xFFFFFFFF), and our slice code in the
kernel doesn't translate the max-value into the actual disk size
which makes disklabel believe that the disk is smaller then it actually
is. This doesn't matter so much for add-on disks but it does for
boot disks where the BIOS is expecting a slice table, yet we want the
disklabel to be able to make full use of the actual size of the disk.
-Matt
Matthew Dillon
<dillon@backplane.com>