Hey! Sorry, I was away for a couple of weeks but I saw jibel anwered most questions We don’t know yet if we are going to commit with full support by the LTS or not. It will really depend on the amount of feedback on 19.10 and if we can get the development as far as we want before officially stamping a 1.0 for official support
Sure, however, you won’t get the zsys specificy themselves (or you will have to manually tag and understand the dataset layout and tagging we are doing). But you will get the benefits from zfs support, including a more advanced grub menu for booting from snapshots, listing machines and so on.
The specifics of dataset layout and tagging will be in the blog post suite on ZFS which is scheduled to be published during September/October.
We (including the kernel team) won’t backport ZFS 0.8.1 to a released version, as per the Stable Release Update policy. There are patches that have been backported in 0.7 to make it work with kernel 5.2 and we won’t risk our user audience by providing a new ZFS version.
As soon as we release the ubiquity code, that will be really easy and avoid you to manually create the tagging which can be error-prone when done manually.
No! If you look at eoan today, you have
/etc/grub.d/10_linux_zfs which is exactly designed to detect current (and other parallel installations) of ZFS system. This is enabled by default and if the script is installed,
/etc/grub.d/10_linux is disabled for ZFS systems.
On zsys, each upgrade (not in eoan, but later on) will produce a new snapshot, whatever the size of the upgrade are. Due to how ZFS manages those deltas, this should be small and compressed. Snapshots automatically made by the system will be garbaged collected automatically after a period of time (which is to be defined) and the granularity will be decreased as well.
If you want those data pools to be persistent, sure (I’m sure the blog posts will shed some lights of it). It means that you will have to handle the revert and snapshots manually on those. Basically, we tried to not tight the hands of sysadmins
Sure, we default UEFI/non UEFI selection will be available as it is in ubiquity today, so you can boot in legacy “bios” mode.
It shouldn’t because we don’t force one pool. The only limitation is that what we call “system datasets” (the one handled automatically by zsys for snapshots/rollback) have to be on the same pool (apart for /boot). Persistent datasets (as told previously, handled manually) can be in any pool. User datasets (basically home datasets) can be on any pool and even splitted.