Project status?

[psy0rz]

It seems the project has been dead for months now? What going on?

[Lockszmith-GH]

I'm interested as well.
@didrocks is there a public facing location where we can see status / project plans from ubuntu/canonical's perspective? or is that something that is never public?

[psy0rz]

The official blog also seems to be down (connection refrused on https://didrocks.fr )

[psy0rz]

I was getting worried, but it seems @didrocks is still active on github, so nothing bad happend to him as a person. :)

Probably busy or other priorities at the moment.

[didrocks]

Thanks for the kinds words :)
No, nothing bad happened, thanks! I haven’t noticed my blog is down, I need to put it up once I get a minute for it.

Unfortunately, we have conflicting priorities with the few people who were working on that project. As you can see on github, we are very active in other parts of ubuntu. Consequently, we were asked to put that project on hold.
At least, as the code is still here, anybody can step up if they want to get things moving before we can get back to it. I’m happy to facilitate and spend time for ramping up anyone interested into this.

[Lockszmith-GH]

Glad to hear you are doing good. And yes, your activity log on GitHub was a good indication its a priorities thing - so thank you for responding here.

What would you consider welcome contribution from the community at this point?
What would you like to see in the PR queue that would be worth your time?

[danboid]

I'd like to see Canonical let @didrocks concentrate on working on zsys or even better have multiple devs focus on getting Ubuntu's ZFS support in good shape. It would be a killer feature if the main zsys bugs could be ironed out and the Ubuntu (server) installer got more ZFS options.

My 2p.

[didrocks]

Sorry for the delayed answer. I think where contributions are welcomed is first in bug fixes (there are cases when it seems the current USERDATA sets are unattached to the system ones, and so, elected for removal). Understanding them and debugging would be a great contribution.

Then, we had this board to track important features and things to fix: https://github.com/orgs/ubuntu/projects/1. Mostly the performance in the go zfs binding is the biggest blocker when you start having a big number of datasets. Also, the do-release-upgrade integration would be awesome (and shouldn’t be too complicated).
Thanks for reaching out, and do not hesitate if you have any other questions.

[danboid]

Then, we had this board to track important features and things to fix: https://github.com/orgs/ubuntu/projects/1. Mostly the performance in the go zfs binding is the biggest blocker when you start having a big number of datasets. Also, the do-release-upgrade integration would be awesome (and shouldn’t be too complicated). Thanks for reaching out, and do not hesitate if you have any other questions.

So it's not currently possible to run 'do-release-upgrade' and have it succeed if you have root on ZFS?

[didrocks]

So it's not currently possible to run 'do-release-upgrade' and have it succeed if you have root on ZFS?

Oh, no, this is working. This was more "advanced integration" like a good UI to show up the upgrade/revert to a previous release :)

[dioni21]

On 11/22/21 06:41, Didier Roche wrote: Sorry for the delayed answer. I think where contributions are welcomed is first in bug fixes (there are cases when it seems the current USERDATA sets are unattached to the system ones, and so, elected for removal). Understanding them and debugging would be a great contribution. Mostly the performance in the go zfs binding is the biggest blocker when you start having a big number of datasets.

Could we have a single dataset for all users, as a config option? Also, why do we need many "root" datasets (/var/*,usr/local)? I could not read the rationale anywhere.

…

-- Atenciosamente, Jonny

-- João Carlos Mendes Luís - Engenheiro de Redes e Sistemas

[Lockszmith-GH]

Segmentation of datasets is one of the powers of ZFS, this can be used to make granular snapshots of certain datasets as well as allow for granular backups (using send/receive).

The more datasets you have, the easier the job of restoration is - should you need to restore something more specific.
Especially when you tie it with scripting that can take care of batch operations.

At least that's the rationale for me.

[almereyda]

ZFS support has left experimental status in the Ubuntu installer, with zsys still being on its track towards v1.0. Ubuntu 22.04 LTS, which will be supported for many years to come, will bring the current state of the utility to the common user.

As there do not seem to be enough capacities within the organisation holding this repository, allow me to ask, if there is a place at Canonical where one can submit an application to specifically work on improving this support? To me, it appears a little unjust to ask the community to provide in kind development and maintenance work on a critical self-developed, low level system component.

I'd love to see first-tier support for the ZFS integration into Ubuntu, and could imagine to dedicate myself to the task. But the boundary context and cooperation conditions need to be perfectly fair and clear. I hope it is not because of hidden legal quarrel with Oracle, due to ZFS being built into the Kernel nowadays, that this work is stalled and put on hold. I bet Canonical would have faded already, if that was the case.

[lciti]

I agree there seem to be insufficient resources allocated to zsys to make it part of mainstream Ubuntu, given some serious outstanding issues like #196. I have been looking at zfsbootmenu for some time, fiddling with it before deciding whether to switch or not. Also, it seems to me that some of the issues with booting from zfs (that possibly make zsys more complex) are due to GRUB only supporting a subset of ZFS (here) and I wonder if investing in trying to improve GRUB's capabilities would solve some of the issues.

[h-2]

Consequently, we were asked to put that project on hold.

I think what @didrocks is trying to say is, that Ubuntu is longer funding work on this, which basically means that it has given up on integrating ZFS properly. I lack the business perspective of Canonical, but I think it's sad how many innovative things never make it; also considering how much developer time went it making them happen in the first place.
It just feels like if they had pushed through just a little bit longer, things would have reached a widely usable state.

Anyway, will be looking out for another distro with good ZFS support (Project Trident unfortunately also shut down).

[danboid]

I would recommend ZFS fans check out GhostBSD, based upon FreeBSD. Most of the open source apps have been ported to FreeBSD but I realise some people depend upon app or kernel feature x which doesn't have a valid freebsd alternative.

It has the most ZFS installation options that I've seen in a distro targetted at 'normal' users and its a very polished take on FreeBSD, which still has better ZFS support than any Linux distro I'm aware of.

NetBSD also has ZFS support OOTB now, you just need to enable it in rc.conf. No ZFS root support in the NetBSD installer yet but that's being worked on.

[h-2]

I would recommend ZFS fans check out GhostBSD, based upon FreeBSD.

I am a FreeBSD user at home, but I need native Linux on my work laptop. That's why I took Ubuntu in the first place. But, yeah, there are alternatives.

[tracing-home]

I landed here due to the "dataset does not exist" error. A difference here is, I do not even run Zsys. There is no encryption and I boot via grub/ext4. On Xubuntu 20.04, zfs-0.8.3-1ubuntu12.13, zfs-kmod-2.0.6-1ubuntu2.1 . By now I have lost my pool's datasets twice with unknown datasets appearing. It could well be due to reboots. Not sure. The snapshots in the pool are sent from a TrueNAS box.

Reading here that support for ZFS is "on hold", and now am experiencing this data loss, is not a good perspective...

Sorry to be whining here. ... :D

Edit: I realize this thread is about zsys. I am mentioning this only because, the error comes up without zsys as well....