FreeBSD / ZFS Upgrade Best Practice Question

J

jrehmer

Is there a best practice for upgrading ZFS pools when ZFS is updated in a FreeBSD release, such as with 14.0? Do most users generally know to do it, or do folks even bother if they aren't interested in a new feature?

There is only a minor mention of 'zpool upgrade' in the 14.0 Release Notes in the note about systems using EFI, so in a way I glossed over it since my systems do not use EFI. Looking through other Upgrade related documentation I don't see specific call-outs about upgrading ZFS pools or running 'zpool upgrade' after an upgrade, and I assume that it is never performed during an upgrade by the freebsd-update process?
 
jrehmer said:
[...] Looking through other Upgrade related documentation I don't see specific call-outs about upgrading ZFS pools or running 'zpool upgrade' after an upgrade, and I assume that it is never performed during an upgrade by the freebsd-update process?
Click to expand...
My advice: be very considerate (careful & conservative) and well-informed before performing a zfs pool upgrade, it's a one way street (precisely the reason why it is not included in a FreeBSD upgrade process I imagine). See also Upgrading a Storage Pool
 
Be very careful before doing a zpool upgrade. I typically do zpool upgrade on pools long after the code is in -CURRENT. And then, only on a scratch pool I use for throw away stuff. And then, only after a zpool checkpoint to allow the pool to revert back to its original -- albeit with whatever was written to the pool since checkpoint is lost.

Yes, you can revert a zpool upgrade using a zpool checkpoint but at the cost of losing all writes to the pool since the checkpoint was made. Thus only do this on a scratch pool you don't mind losing any data.

When I do create new pools I set the zpool option to disable block_cloning from the get-go. My new pools do not include all new features.

I will probably consider upgrading my zpools, one by one starting with the throwaway pool, then my sandbox machine and finally the others, maybe next summer, depending on the bug reports, what people are discussing on the mailing lists, and my own experience over the months. It will take months of patiently watching for bugs.

I run 15-CURRENT.
 
I have been running FreeBSD on my home server since at least 10.1-RELEASE and have booted from ZFS for most of that time, I am no expert but have some experience with this.

I am currently on 14.0-RELEASE and have not been conservative with my upgrades as there is nothing important on there that isn't backed up. I have only ever had one issue with upgrading a pool which appears to be the one that catches most people out - make sure you update the bootcode if the system boots from the pool being upgraded. Failure to do this may result in a system that will not boot though I can personally attest it is fairly easy to fix with a live cd/usb.

If it does boot from zfs I advise you read the bootstrapping section in gpart(8) as well as gptzfsboot(8) if the system is BIOS based or uefi(8) and loader.efi(8) if the system is UEFI based. If you aren't sure if the system is BIOS or UEFI you can run sysctl machdep.bootmethod to check.

A useful feature of zfs which may be worth reading up on before upgrading is the option to set a compatibility property on a pool using zpool set compatibility=file[,file] pool (see zpool-set(8) for the set command and zpoolprops(7) for details of the compatibility property)
FreeBSD ships with some pre-configured compatibility files in /usr/share/zfs/compatibility.d/. Applying one or more of these compatibility files will limit the features which are enabled when the upgrade command is run instead of enabling everything which is the default.
 
I basically use newest stable branch and main branch.
And I upgrade ZFS pool only when new stable branch is JUST CREATED, means ZFS codes of main and newest stable branch 100% matches.
The procedure is basically as follows.
  1. Just after the schedule for new *.0-Release is announced, start closely watching freebsd-current ML and Bugzilla whether ZFS-related severe problem is happening or not.
  2. If ZFS codes seems to be fine as of 1. when new stable branch is created, update main environment to the point new branch is created.
  3. Upgrade previous stable branch to newly created stable branch.
  4. Update ALL boot codes using main branch'es one.
  5. Upgrade ZFS pool (root on ZFS) of main branch.
  6. If 5. goes sane, upgrade ZFS pool (also root on ZFS) of stable branch.
This time (stable/14 is created), ZFS codes for new features of main seemed to be dangerous (especially block_cloning), I decided not to upgrade ZFS pool.
 
I'm agreement with cy@ cracauer@ Erichans on use of zpool upgrade. The fact that it's basically irreversible (noted caveats in #4) means proceed with extreme caution.
My opinion is to only zpool upgrade when the new version has features that you "must have and are going to use" and make sure you update all boot blocks on all boot devices if you are using "root on ZFS" before you reboot the upgraded zpool.
If I am going to zpool upgrade I update the bootblocks first before doing the zpool upgrade simply because the new bootblocks understand the old version while the old bootblocks probably don't understand the new version.
 
I wish I could cherry-pick which specific features I want when upgrading. AFAIK it is all or nothing right now.

I never want to upgrade to allow all features that my current platform offers. Because I want to keep my pools readable by both Linux and FreeBSD.
 
cracauer@ said:
I wish I could cherry-pick which specific features I want when upgrading. AFAIK it is all or nothing right now.
Click to expand...
Have a look at zpool-features(7):
Code: 
DESCRIPTION
       ZFS pool	on-disk	format versions	are specified via "features" which re-
       place the old on-disk format numbers (the last supported	on-disk	format
       number is 28).  To enable a feature on a	pool use the zpool upgrade, or
       set  the	feature@feature-name property to enabled.  Please also see the
       "Compatibility feature sets" section for	information  on	 how  sets  of
       features	may be enabled together.
This suggests to me that you actually can cherry-pick, at least where zpools are concerned that do not have "the old on-disk format numbers" as mentioned.

Added:
You have either a "real legacy" ZFS version zpool with "the old on-disk format numbers" or you have a zpool with Feature Flags. Feature Flags has more info; the Reference Material mentions
There it is stated that you can even enable a feature in an "old on-disk format numbers" zpool:
Enabling a feature automatically upgrades the pool legacy version to
version 1000
Click to expand...
whereby you will have entered "Feauture Flags" territory.
 
I think when you do zpool upgrade you have the potential to enable the new features, maybe some are enabled by default but I think most are not enabled.
My understanding if don't actually enable any of the new features I think the old boot blocks would work.
 
You must log in or register to reply here.
Back
Top