© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I had the same issue here.
Edit 3: Went ahead disabled zsys and migrated to sanoid + save alias -> works properly and takes care of the space properly too.
No more issues with update-grub, bpool filling up and tree million snapshots when installing many packages.
----
So far it seems like only zsys is affected and its services, so automatic snapshotting on apt install currently does not work for me.
I do have to add that I created my own snapshot command before upgrading anything important after having quite a few issues with the way zsys does it trying to restore my system to a working state (kernel and apt-packages staying accross restored snapshots of zsysctl, which ... I could not really grasp why it would do that).
Maybe that has something to do with it?
Linux derpmachine 5.13.0-
For now I dont really need it ... sanoid and my command works totally fine the regular zfs-way.
Already restored a few times after a few broken kernel testings and playing with different DEs.
---
Edit 1:
Reboot usually solves it.
Also found this here in regards to fine-tuning zsys yourself, including increasing the timeout for the service:
https:/
----
Edit 2:
Despite the above from Edit 1 - it does not help. Increasing the timeout doesn't help. Messing with the parameters does not help. Even if you have sufficient space.
Just waiting for a few minutes after reboot the service crashes back again. Why? Absolutely no clue. There's no error-log or anything pointing towards it.
Despite having enought space, despite zfs in itself reporting everything is fine.
I might have to add that I'm also using the workaround for docker with an ext4 mount on /var/lib/docker to solve the performance issues but I doubt that has anything to do with it.
Seems totally unreliable for me at this state so I disabled it completely.
Destroyed all snapshots related to it and moved completely to sanoid which seems much more battle tested and stable in its purpose, which I verified is super fine with purging and snapshoting in itself.
If anything bad happens now I just boot to the shell and run the restore on zpool and bpool manually.
I do not understand why there is a need for a zsys daemon that's working as unreliable as this if zfs is working perfectly fine in itself out of the box.
Seems like this implementation behind zsys needs quite some work and/or refactoring done on the core concept before this can be considered stable (no offense, just guessing).
Also with a look at sanoid which appears to work much better in its current implementation ontop of zfs at least on the current LTS before 22.04 happens next year.
Oh wow - didn't even realize this issue persists since a year now (first reported december 2020).
That's not something trivial and not something to underestimate considering the design behind the two pools - bpool and rpool and bpool being so limited in space having no ability to grow it easily on devices like a laptop.
So my advice to anyone using Ubuntus Experimental ZFS-Install for now will be to disabled ZSys ASAP and move to sanoid until I see this addressed ....