# sgdisk -n1:0:0 -t1:BF01 /dev/disk/by-id/scsi-SATA_disk1 Run this if you need legacy (BIOS) booting: # sgdisk -a1 -n2:34:2047 -t2:EF02 /dev/disk/by-id/scsi-SATA_disk1 Run this for UEFI booting (for use now or in the future): # sgdisk -n3:1M:+512M -t3:EF00 /dev/disk/by-id/scsi-SATA_disk1 Run this in all cases: # sgdisk -n9:-8M:0 -t9:BF07 /dev/disk/by-id/scsi-SATA_disk1
What I don't understand in this example is the first partition. Reading through the man page of sgdisk it's not clear to me if the first partition is only of size one block or if it covers essentially the whole device. In the latter case that would mean that all the other created partitions are created within the first one? What makes me wonder is the following sentence in the man page:
A start or end value of 0 specifies the default value, which is the start of the largest available block for the start sector and the end of the same block for the end sector.
"The same block" sounds like one block of the physical device, so either e.g. 512 Byte or 4k Byte of data? Or does it mean some contiguous amount of storage, spanning multiple logical/physical blocks in the end?
It's important to understand this for me because of the following sentence in the wiki:
The root pool does not have to be a single disk; it can have a mirror or raidz topology. In that case, repeat the partitioning commands for all the disks which will be part of the pool. Then, create the pool using zpool create ... rpool mirror /dev/disk/by-id/scsi-SATA_disk1-part1 /dev/disk/by-id/scsi-SATA_disk2-part1 (or replace mirror with raidz, raidz2, or raidz3 and list the partitions from additional disks).
As you can read, only the first partition is put into the pool, the others created above are not mentioned at all. What I'm not understanding is if the other partitions are part of
part1 and therefore implicitly available in the pool as well or not used for the pool at all. For example, GRUB is installed into one of the other partitions, no reference to the ZFS pool in this case:
# mkdosfs -F 32 -n EFI /dev/disk/by-id/scsi-SATA_disk1-part3 [...] # echo PARTUUID=$(blkid -s PARTUUID -o value \ /dev/disk/by-id/scsi-SATA_disk1-part3) \ /boot/efi vfat nofail,x-systemd.device-timeout=1 0 1 >> /etc/fstab
That reads to me like
part3 is not part of the ZFS pool and therefore used individually. But how does that fit to the size of
part1? A partition of only one block doesn't seem to make much sense, while if
part3 is contained in
part1 somehow, that would mean it is part of the ZFS pool, but addressed without it as well?
I need to understand how redundancy is provided for the boot partitions in a setup with multiple devices and partitions like in the above example. Compared to
mdadm, the overall goal is a RAID10 setup, where always two devices are mirrored and the partitions of those devices are then striped over all mirrors. In the end, with 6 disks one would one 3 times the storage for the boot partitions and the root pool. ZFS is capable of doing that in general, I'm just not sure what is part of the pool and if redundancy covers the boot partitions as well.
My current feeling is that it's not the case and I would need
mdadm to make the boot partitions redundant. Simply because the GRUB example above accesses some specific disk and partition, a physical device, not some logical mirror created by ZFS. Additionally, that partition is formatted with FAT32 instead of ZFS. This doesn't read like ZFS is caring about any of those partitions at all.
So in the end, does ZFS support a RAID10 setup comparable to that possible with
mdadm including all boot partitions, root and such, really everything?