DragonFlyBSD

Matthew Dillon wrote:

:Booting DragonFly from disklabel64 slice has problems:
: - using HAMMER it almost works: one module can't be read
:Reading /modules/acpi.ko fails; after booting (host can run without ACPI)
:(i.e. by kernel) acpi.ko can be read and contents is correct.
:(files on test HAMMER system are just cpdup'ed from a working system;
:cmp verified acpi.ko is readable and has same contents)

It sounds like the hammer fs read code in the boot loader isn't
handling all the cases properly.

Yes, we should try and fix that. Thomas, can you compile hammerread.c
and try to find out why it is having a problem?

I'm going to be blunt on the HAMMER boot thing... I don't actually
like the idea, because the boot code can't run the UNDO's after a
crash and so might not be able to find the kernel and other boot
related files. I would rather just boot from a small UFS /boot
partition and then have the kernel mount HAMMER as the root.

I guess I'll have to deal with changing the installer to create a
BOOT+HAMMER setup instead of a straight HAMMER setup.

However so far nobody had problems since we fixed the last bugs. I
absolutely agree that we should have the boot code reading the UNDO, and
also multi-volume HAMMER file systems will not work with the boot loader
(will never). However I think for a simple setup, having just one
HAMMER file system should be supported and perfectly fine.

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

On Mon, Jun 22, 2009 at 07:28:20PM -0700, Matthew Dillon wrote:

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

What about gpt ? I had the impression it was meant to replace fdisk for big
storage volumes...

On Tue, Jun 23, 2009 at 10:47:56AM -0700, Matthew Dillon wrote:

:What about gpt ? I had the impression it was meant to replace fdisk for big
:storage volumes...

Many BIOSes (most, probably) do not understand GPT slices and
can't boot from it.

I'm sure this will change but adoption has been very slow.

I was thinking about gpt(8): the program, not the on-disk structure itself.
It is able to create a special /boot mbr slice for old bioses and still address
more than 2TB for all the rest.

Shouldn't this be used instead of fdisk(8) in the future ?

:
:New submission from Thomas Nikolajsen <thomas.nikolajsen@mail.dk>:
:
:Booting DragonFly from disklabel64 slice has problems:
: - using HAMMER it almost works: one module can't be read
:Reading /modules/acpi.ko fails; after booting (host can run without ACPI)
:(i.e. by kernel) acpi.ko can be read and contents is correct.
:(files on test HAMMER system are just cpdup'ed from a working system;
:cmp verified acpi.ko is readable and has same contents)

It sounds like the hammer fs read code in the boot loader isn't
    handling all the cases properly.

:Also doing ls command in loader on HAMMER file system can crash loader.
:It seems like libstand/hammerread has an issue.
:
: - using UFS it doesn't work: I just see a spinning bar
:It doesn't show any text, like BTX..
:
:I had the impression that disklabel64 booting should be working
:(since commits below); is this correct?

UFS should work.

:Is zeroing slice start before making bootable disklabel still needed?
:If yes: is it enough to zero 16KB, like disklabel32.

Zeroing is still needed.

:I was going to update disklabel64.8 to include boot info again;
:but will hold it back until this issue is resolved.

I'm going to be blunt on the HAMMER boot thing... I don't actually
    like the idea, because the boot code can't run the UNDO's after a
    crash and so might not be able to find the kernel and other boot
    related files.  I would rather just boot from a small UFS /boot
    partition and then have the kernel mount HAMMER as the root.

I guess I'll have to deal with changing the installer to create a
    BOOT+HAMMER setup instead of a straight HAMMER setup.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

:However so far nobody had problems since we fixed the last bugs. I
:absolutely agree that we should have the boot code reading the UNDO, and
:also multi-volume HAMMER file systems will not work with the boot loader
:(will never). However I think for a simple setup, having just one
:HAMMER file system should be supported and perfectly fine.
:
: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'm also a bit worried about BIOS addressability with large disks.
    If someone installs a terrabyte disk with HAMMER on it, hammerread
    might have to access very high numbered sectors.  I don't trust the
    BIOS to properly use 48-bit sector addressing.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Another interesting issue here which I really think puts the nail in
coffin is that we really want to be able to use more complex access
schemes, such as vinum, for these large filesystems. I don't want to
have to depend on something like the BIOS fake-raid, its just too severely
limiting.

With a small UFS /boot we can make the primary root filesystem whatever
    we want... from multi-volume mounts to vinum or any other scheme we
    choose, including eventually mounts named by serial number.

The more I think about it, the more I really want us to default to
    a small UFS /boot.  Here's another example... lets say we wanted to
    support encrypted disks.  The information on the UFS /boot would not
    have to be encrypted per-say, since it's just a tiny boot-only partition
    containing no production data.  It could, however, contain sufficient
    information to allow the system to auto-boot the encrypted root disk.

For example, the /boot booted kernel could query the local environment,
    such as the network, and acquire sufficient information to mount its
    encrypted root.

--

If we reserved space for a /boot by default on every disk we disklabel,
    it could lead to some fairly impressive booting and recovery options.
    I'd like it to be the new concept for the 'a' partition.  Make 'a'
    always be a small /boot partition.

-Matt

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

:What about gpt ? I had the impression it was meant to replace fdisk for big
:storage volumes...
:
:--
:Francois Tigeot

Many BIOSes (most, probably) do not understand GPT slices and
    can't boot from it.

I'm sure this will change but adoption has been very slow.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

:On Tue, Jun 23, 2009 at 10:47:56AM 0700, Matthew Dillon wrote:
:>
:> :What about gpt ? I had the impression it was meant to replace fdisk for big
:> :storage volumes...
:>
:> Many BIOSes (most, probably) do not understand GPT slices and
:> can't boot from it.
:>
:> I'm sure this will change but adoption has been very slow.
:
:I was thinking about gpt(8): the program, not the on-disk structure itself.
:It is able to create a special /boot mbr slice for old bioses and still address
:more than 2TB for all the rest.
:
:Shouldn't this be used instead of fdisk(8) in the future ?
:
:-
:Francois Tigeot

It has a mbr compat feature but BIOSes often can't deal with it.  i.e.
    it isn't as compatible as was originally intended.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>