Re: [issue1407] disklabel64 boot problem

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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>