Ubuntu's ZFS Trajectory Is Going From Exciting To Even More Exciting

[phoronix]

Phoronix: Ubuntu's ZFS Trajectory Is Going From Exciting To Even More Exciting

While it is already exciting to have the Ubuntu 19.10 desktop easily support installations to a root ZFS file-system, moving ahead with their original Zsys effort it should be even more exciting for Ubuntu storage possibilities on both the desktop and server...

http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-ZFS-Zsys-More-Exciting

[discordian]

Pff, you guys aint true Hipsters unless you use bcachefs

[skeevy420]

0.8.2 didn’t make it on time for a good integration and tests in Eoan. So, we backported some post-release upstream fixes as they fit, like newer kernel compatibility, to provide the best user experience and reliability.

Dammit, Ubuntu. Some things you just do not cherry pick.

Anyways. Liked most of what I read over there. I'd have gone with a different /boot strategy. /boot being a GRUB feature compatible zpool and /boot/grub being ext4 just seems dumb and I hope it's just a temporary measure until they can put a team on GRUB to get it supporting all of ZFS's features so we don't have to use limited pools anymore (perhaps team up with Project Trident on that because a cohesive ZFS on Linux root experience is one of their new goals as well).

[jrch2k8]

Dammit, Ubuntu. Some things you just do not cherry pick.

Anyways. Liked most of what I read over there. I'd have gone with a different /boot strategy. /boot being a GRUB feature compatible zpool and /boot/grub being ext4 just seems dumb and I hope it's just a temporary measure until they can put a team on GRUB to get it supporting all of ZFS's features so we don't have to use limited pools anymore (perhaps team up with Project Trident on that because a cohesive ZFS on Linux root experience is one of their new goals as well).

Grub and ZFS has been broken for years now, outside forcing version 5000 at pool creation(which is not a good idea anymore on ZoL), so is either accept an small boot partition or use systemd-boot(other may work as well, i'm just 100% sure systemd-boot works fine on any configuration i've tried so far).

I'm guessing they went with boot partition to avoid the very small but very vocal systemd hater crybabies crying all over the place

[sireangelus]

Grub and ZFS has been broken for years now, outside forcing version 5000 at pool creation(which is not a good idea anymore on ZoL), so is either accept an small boot partition or use systemd-boot(other may work as well, i'm just 100% sure systemd-boot works fine on any configuration i've tried so far).

I'm guessing they went with boot partition to avoid the very small but very vocal systemd hater crybabies crying all over the place

i don't see proxmox having any problems doing 1 partition zfs for everythings

[skeevy420]

Grub and ZFS has been broken for years now, outside forcing version 5000 at pool creation(which is not a good idea anymore on ZoL), so is either accept an small boot partition or use systemd-boot(other may work as well, i'm just 100% sure systemd-boot works fine on any configuration i've tried so far).

I'm guessing they went with boot partition to avoid the very small but very vocal systemd hater crybabies crying all over the place

That and people with slightly older systems like mine are stuck with GRUB and can't make use of systemd-boot (and never will unless it adopts an EFI emulation/compat/whatever layer for BIOS and non-UEFI systems).

IMHO, they should use an entire filesystem for /boot and not piece it out into multiple partitions like they're describing. I get why they'd decide to go that route, but it just seems that if they're going to add unnecessary complexity, might as well use a straight ZFS partition/pool schemes over ZFS+EXT4 mixed partition/pool schemes (obviously I'm skipping EFI and FAT32).

Bootloaders and BIOS/UEFI and file system features are becoming the new i286/i686/x86_64 splits in the Linux world. BTRFS, ZFS, Stratis, & LVM+LUKS, basically every & all Linux advanced file system, have issues in regards to bootloaders, supported features, and works everywhere/universal -- Pick two, nothing modern and up-to-date on Linux applies to all three.

[jrch2k8]

i don't see proxmox having any problems doing 1 partition zfs for everythings

you can do it as long as you create the pool with version 5000 and never run zpool upgrade -a, once you enable encryption/largednodes/special_small_blocks among others grub stops seeing the partition and bye bye boot.

Also i'm not sure if proxmox is using an older version of ZoL to avoid breaking grub like 0.6.9 series or is using another implementation through FUSE

[jrch2k8]

IMHO, they should use an entire filesystem for /boot and not piece it out into multiple partitions like they're describing. I get why they'd decide to go that route, but it just seems that if they're going to add unnecessary complexity, might as well use a straight ZFS partition/pool schemes over ZFS+EXT4 mixed partition/pool schemes (obviously I'm skipping EFI and FAT32).
.

Is simple, BIOSes are hard, dumb and never had any sort of standard to do handoff to boot the the kernels, so projects like GRUB growed into such monsters because they had to replicate kernel functions to set an environment good enough to handoff the boot process to the kernel.

For example:

• Grub actually need a proper filesystem to read the filesystem where the boot partition is to be able to exec the kernel, if the filesystem doesn't match it cannot handoff the boot to the kernel because it cannot see it, see is a circle.

So technically speaking grub is sort of a smaller kernel to boot the bigger kernel, hence any new feature on any detrimental part like a filesystem need to be applied to both the kernel and GRUB in parallel or the handoff won't happen and ZoL simply goes forward in development way faster than GRUB does and ZFS is orders of magnitude way more complex than something like EXT4 or XFS, so is not that easy for the GRUB to keep current.

UEFI on the other hand is really dumb and simple with a proper standard, so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot, hence systemd on UEFI is able to boot anything simply because the handoff is done form the UEFI to the kernel directly and the kernel knows exactly what to do from there regardless of features

[skeevy420]

Is simple, BIOSes are hard, dumb and never had any sort of standard to do handoff to boot the the kernels, so projects like GRUB growed into such monsters because they had to replicate kernel functions to set an environment good enough to handoff the boot process to the kernel.

For example:

• Grub actually need a proper filesystem to read the filesystem where the boot partition is to be able to exec the kernel, if the filesystem doesn't match it cannot handoff the boot to the kernel because it cannot see it, see is a circle.

So technically speaking grub is sort of a smaller kernel to boot the bigger kernel, hence any new feature on any detrimental part like a filesystem need to be applied to both the kernel and GRUB in parallel or the handoff won't happen and ZoL simply goes forward in development way faster than GRUB does and ZFS is orders of magnitude way more complex than something like EXT4 or XFS, so is not that easy for the GRUB to keep current.

UEFI on the other hand is really dumb and simple with a proper standard, so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot, hence systemd on UEFI is able to boot anything simply because the handoff is done form the UEFI to the kernel directly and the kernel knows exactly what to do from there regardless of features

You don't say

Like I stated afterwards, there isn't one solution that covers everything. The two prominent ones for desktop users are systemd-boot and GRUB. systemd-boot basically omits any non-systemd distribution as well as legacy systems whereas GRUB2 works everywhere but is slow to adopt features which basically means that even if one is a systemd distribution they have to support GRUB2 unless they go the Clear route and start defining their own x86_64v2 standard and omit legacy support.

How come it isn't possible to sort of emulate the UEFI method by having the mbr load an interface and init kernel from a fixed-size fat32 or ext4 partition and then using that init kernel+ramdisk for feature support? Basically, move the initial ramdisk down a level from "loaded by GRUB" to "is GRUB" and KVM from the boot system to host system if that makes sense. That way all the bootloader/GRUB would need to know is just enough to understand FAT32/EXT4 and loading the kernel -- decrease the bootloader's complexity by handing it off to the init system. I call it -- LUB -- Linux Unified Bootloader -- we know fat32 and how to load a Linux kernel; you figure it out from there.

[jrch2k8]

You don't say

Like I stated afterwards, there isn't one solution that covers everything. The two prominent ones for desktop users are systemd-boot and GRUB. systemd-boot basically omits any non-systemd distribution as well as legacy systems whereas GRUB2 works everywhere but is slow to adopt features which basically means that even if one is a systemd distribution they have to support GRUB2 unless they go the Clear route and start defining their own x86_64v2 standard and omit legacy support.

How come it isn't possible to sort of emulate the UEFI method by having the mbr load an interface and init kernel from a fixed-size fat32 or ext4 partition and then using that init kernel+ramdisk for feature support? Basically, move the initial ramdisk down a level from "loaded by GRUB" to "is GRUB" and KVM from the boot system to host system if that makes sense. That way all the bootloader/GRUB would need to know is just enough to understand FAT32/EXT4 and loading the kernel -- decrease the bootloader's complexity by handing it off to the init system. I call it -- LUB -- Linux Unified Bootloader -- we know fat32 and how to load a Linux kernel; you figure it out from there.

This can be done today but the problem is people:

• Expect most distros to follow a guideline on partitioning for boot is gonna take a long freaking while.
• Every whinner under the sun will come with some idiotic reason why doing this will break half the universe.
• If Grub tries to remove code and move into a standard for force distros to get in line, every systemd haters, tinfoil hater, paranoic neckbeard out there will cry murder and will accuse Red Hat and Lennart of somehow plan a coup in tandem with the reptilians.

and Lastly we have UEFI in any recent hardware (even my FX6100 support UEFI just fine) and will stay for a good while, hence most devs will think twice going through all that pain just to support some legacy systems that are stuck on BIOS mode, honestly i would not do it if i were a distro maintainer or grub dev