ZFS and GPT partitions, last 8 MB?

[Richard Laager]

It looks like the 8MB at the end (partition #9) is just there for EFI
booting.

It's not. This is a Solaris thing, though I haven't found anything on
Solaris that uses that partition either. AFAIK, it should be safe to
delete. Test in a lab or virtual machine environment first, of course.

[Omen Wild]

When I created the pool I gave ZFS the entire disks so it formatted them
----- Begin quote -----
Partition Table: gpt
Number Start End Size File system Name Flags
1 1048576B 2000390528511B 2000389479936B zfs zfs
9 2000390528512B 2000398917119B 8388608B
----- End quote -----

I have a question about the GPT partitions ZFS uses. I am guessing ZFS
aligns the first partition at 1MB to get alignment across all
different types of storage.

It looks like the 8MB at the end (partition #9) is just there for EFI
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?

This came up because I'm trying to figure out if I could break my ZFS
mirror and LUKS encrypt the underlying disk and then re-mirror
(thread: Encrypt underlying disks after the fact?).

If ZFS isn't using that last 8MB then I could redo partition 1 to span
the entire disk and have enough blocks to reformat with LUKS.

Thanks

[Brian Behlendorf]

It looks like the 8MB at the end (partition #9) is just there for EFI
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?

Partition #9 is created by the tools to be consistent with the Illumos
behavior but is otherwise completely unused. You should be able to
remove it safely without ill effect at least when using ZoL. I'm not
sure how things will behave on other platforms.

Thanks,
Brian

This came up because I'm trying to figure out if I could break my ZFS
mirror and LUKS encrypt the underlying disk and then re-mirror
(thread: Encrypt underlying disks after the fact?).
If ZFS isn't using that last 8MB then I could redo partition 1 to span
the entire disk and have enough blocks to reformat with LUKS.
Thanks

[Schlacta, Christ]

This is a perfect time to reintroduce and old request:
Can we have zfs create an extra 1mb partition, preferably at the start of
the disk, and set it up as bios_grub, possibly with an optional flag, so
that we can use whole disks when creating bootable pools?

It looks like the 8MB at the end (partition #9) is just there for EFI

Post by Omen Wild
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?

Partition #9 is created by the tools to be consistent with the Illumos
behavior but is otherwise completely unused. You should be able to
remove it safely without ill effect at least when using ZoL. I'm not
sure how things will behave on other platforms.
Thanks,
Brian

Post by Omen Wild
This came up because I'm trying to figure out if I could break my ZFS
mirror and LUKS encrypt the underlying disk and then re-mirror
(thread: Encrypt underlying disks after the fact?).
If ZFS isn't using that last 8MB then I could redo partition 1 to span
the entire disk and have enough blocks to reformat with LUKS.
Thanks

[Gregor Kopka]

Chris,

according to https://github.com/ryao/zfs-overlay/blob/master/zfs-install
i used sgdisk to create another partition (2) from 34 to 2047 which was
enough to hold grub2 data for me and boot from it without any problems.

Number Start (sector) End (sector) Size Code Name
1 2048 41945079 20.0 GiB BF01 boot
2 34 2047 1007.0 KiB EF02 grub
3 41945088 44042239 1024.0 MiB BF01 data-zil-1
4 44042240 117231374 34.9 GiB BF01 data-cache-1

(ok, i probably shouldn't put ZIL and CACHE for another pool onto the
boot SSDs but i did it anyway and it works nicely since the boot pool is
99% idle after the server started).

Since /sgdisk -n2:48:2047 -t2:EF02 -c2:bios_grub//<dev>/ is all you
need to make the partition after a zpool create on an empty drive, i
don't see a need to build this into ZFS.

Gregor

Post by Schlacta, Christ
Can we have zfs create an extra 1mb partition, preferably at the start
of the disk, and set it up as bios_grub, possibly with an optional
flag, so that we can use whole disks when creating bootable pools?
It looks like the 8MB at the end (partition #9) is just there for EFI
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?
Partition #9 is created by the tools to be consistent with the Illumos
behavior but is otherwise completely unused. You should be able to
remove it safely without ill effect at least when using ZoL. I'm not
sure how things will behave on other platforms.
Thanks,
Brian
This came up because I'm trying to figure out if I could break my ZFS
mirror and LUKS encrypt the underlying disk and then re-mirror
(thread: Encrypt underlying disks after the fact?).
If ZFS isn't using that last 8MB then I could redo partition 1 to span
the entire disk and have enough blocks to reformat with LUKS.
Thanks

[Daniel Davis]

I thought that it was best to make your rpool out of a partition vs
whole disk. So I wind up always making my own partitions for root pools
anyway. And I need very few efi boot (one and a copy for the whole
machine) partitions.

Whereas for storage pools whole disk is best and having a little space
at the end is nice in case you have slightly different sizes that would
give you problems for replacement and need to adjust the partition a
little bit.

So I don't see a default to add space for efi boot on storage pool
disks. Please correct me.

--
Dan Davis

Post by Gregor Kopka
Chris,
according to
https://github.com/ryao/zfs-overlay/blob/master/zfs-install i used
sgdisk to create another partition (2) from 34 to 2047 which was
enough to hold grub2 data for me and boot from it without any problems.
Number Start (sector) End (sector) Size Code Name
1 2048 41945079 20.0 GiB BF01 boot
2 34 2047 1007.0 KiB EF02 grub
3 41945088 44042239 1024.0 MiB BF01 data-zil-1
4 44042240 117231374 34.9 GiB BF01 data-cache-1
(ok, i probably shouldn't put ZIL and CACHE for another pool onto the
boot SSDs but i did it anyway and it works nicely since the boot pool
is 99% idle after the server started).
Since /sgdisk -n2:48:2047 -t2:EF02 -c2:bios_grub//<dev>/ is all you
need to make the partition after a zpool create on an empty drive, i
don't see a need to build this into ZFS.
Gregor

Post by Schlacta, Christ
Can we have zfs create an extra 1mb partition, preferably at the
start of the disk, and set it up as bios_grub, possibly with an
optional flag, so that we can use whole disks when creating bootable
pools?
It looks like the 8MB at the end (partition #9) is just there for EFI
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?
Partition #9 is created by the tools to be consistent with the Illumos
behavior but is otherwise completely unused. You should be able to
remove it safely without ill effect at least when using ZoL. I'm not
sure how things will behave on other platforms.
Thanks,
Brian
This came up because I'm trying to figure out if I could break my ZFS
mirror and LUKS encrypt the underlying disk and then re-mirror
(thread: Encrypt underlying disks after the fact?).
If ZFS isn't using that last 8MB then I could redo partition 1 to span
the entire disk and have enough blocks to reformat with LUKS.
Thanks

[Omen Wild]

Post by Brian Behlendorf

It looks like the 8MB at the end (partition #9) is just there for EFI
booting. Would I harm anything (besided EFI booting) by removing it?
Do tools/OSs expect/require that partition if I am not EFI booting?

Partition #9 is created by the tools to be consistent with the Illumos
behavior but is otherwise completely unused. You should be able to
remove it safely without ill effect at least when using ZoL. I'm not
sure how things will behave on other platforms.

Thanks Brian and Richard. I'll put that partition down in the "definitely
not needed" category and take advantage the unused space to expand
partition #1 into that space so the LUKS header will fit.