Other Status of ZFS Overlay and/or unionfs

J

jef

Every time I need to do a "major" version upgrade to my jail hosts and their multiple jails, I swear that I will find a better way to do it for next time. One of the "obvious" ways would be to use an overlay filesystem but FreeBSD's implementation of ZFS still does not support that feature.

From what I have dug up with search, it doesn't look like it's been discussed much at all in the mailing lists or forums, and very little since around 2010. Is there any work being done in this area that anyone here is aware of?

mount_unionfs(8) used to be considered "experimental" and not robust. It doesn't look like this warning has changed in 11.1-RELEASE

unionfs(8) doesn't have the same kind of dire warning and appears to have been added c. 2015, as a port for 10.3-RELEASE using FUSE. Any ideas on how robust this implementation is?
 
TLDR use zfs Boot Environments for the host systems -- it's what you want sysutils/beadm-devel & beadm(). You may need to adjust your zfs setup if its not standard (via the installer) feel free to post output of zfs list -o canmount,mounted,mountpoint,name if you need help with that.

The gist is that the active system's zfs dataset can be snapshotted and used as a basis for a new, copy-on-write, space for subsequent upgrade & rollback. It takes a wee while to get your head around it but once you do, you'll never go back. http://www.callfortesting.org/bhyve-boot-environments/ from Michael Dexter has some longer explanations and some even more clever tricks such as exposing the boot environment back into bhyve to test it before you even upgrade at all. gonzo tech wizardry!

BTW if you build from source, there is this amazing gem https://svnweb.freebsd.org/base/head/tools/build/beinstall.sh which Does The Right Thing - creates a boot environment, installs into it, upgrades the packages in the new BE, and finally merges in any changes to /etc for you.

For jails, mine are reproducible with any real data in a zfs dataset in the jail host, so I snapshot the main datasets, nuke the jails, and re-run ansible to re-create the new upgraded jails. Might not work for everybody.
 
Thanks! I'll take a look at etcupdate(8) as that may prove valuable in resolving the "worst" of the problems. I'll also look again at sysutils/beadm to see how it handles recursive clones, mounts, and destroys.

I track RELEASE these days on most of my boxes with freebsd-update(8) so it may take a little to apply the "tricks" you suggest to those procedures.

Great lead!
 
You must log in or register to reply here.
Back
Top