Hello forum.
I've been reading a couple of documents about ZFS' on-disk format and the structure of vdev labels and its got me thinking about whether it might be possible to boot FreeBSD directly from a pool comprised of whole disks using GRUB, without any underlying partition structure.
The two sources I read (links below) state that a zpool vdev contains four copies of a vdev label, each one 256KiB in size, with two copies located at the beginning of the disk and two copies at the end. Each of these labels starts with just under 16KiB of empty space, for "avoiding conflicts with disk labels".
Following the two labels at the beginning of the disk is another 3.5MiB of empty space, designated for boot code.
I'm wondering whether it would be possible to embed all the bootcode required to boot directly from the pool into these empty spaces, thus avoiding the requirement to partition the disks and set aside a small partition for bootcode.
GRUB documentation describes the following image files:
I'm going to try this out later when I have some time, but has anyone else tried it with any success? If this could be made to work, it might remove one layer of complexity from typical root-on-ZFS setups. What other pros or cons can people think of?
It would be good if something similar could be done with FreeBSD's native ZFS boot code, but I think they're reliant on a partition structure.
JM
Refs:
http://www.osdevcon.org/2009/slides/zfs_internals_uli_graef.pdf
http://pages.cs.wisc.edu/~cs537-3/notes/Zhang_lecture/2_zfs_internals.pdf
I've been reading a couple of documents about ZFS' on-disk format and the structure of vdev labels and its got me thinking about whether it might be possible to boot FreeBSD directly from a pool comprised of whole disks using GRUB, without any underlying partition structure.
The two sources I read (links below) state that a zpool vdev contains four copies of a vdev label, each one 256KiB in size, with two copies located at the beginning of the disk and two copies at the end. Each of these labels starts with just under 16KiB of empty space, for "avoiding conflicts with disk labels".
Following the two labels at the beginning of the disk is another 3.5MiB of empty space, designated for boot code.
I'm wondering whether it would be possible to embed all the bootcode required to boot directly from the pool into these empty spaces, thus avoiding the requirement to partition the disks and set aside a small partition for bootcode.
GRUB documentation describes the following image files:
- boot.img: 512 bytes, to be written to sector 0 of disk. Sector location of diskboot.img hardcoded into it.
- diskboot.img: 512 bytes, first sector of core.img. Sector location of core.img hardcoded into it.
- core.img: Variable size ~several tens of kilobytes. Main part of GRUB.
I'm going to try this out later when I have some time, but has anyone else tried it with any success? If this could be made to work, it might remove one layer of complexity from typical root-on-ZFS setups. What other pros or cons can people think of?
It would be good if something similar could be done with FreeBSD's native ZFS boot code, but I think they're reliant on a partition structure.
JM
Refs:
http://www.osdevcon.org/2009/slides/zfs_internals_uli_graef.pdf
http://pages.cs.wisc.edu/~cs537-3/notes/Zhang_lecture/2_zfs_internals.pdf
