svn commit: r303630 - in head/sys: boot/zfs cddl/boot/zfs

Andriy Gapon avg at FreeBSD.org
Mon Aug 22 08:22:51 UTC 2016


On 01/08/2016 22:37, Allan Jude wrote:
> Author: allanjude
> Date: Mon Aug  1 19:37:43 2016
> New Revision: 303630
> URL: https://svnweb.freebsd.org/changeset/base/303630
> 
> Log:
>   Make boot code and loader check for unsupported ZFS feature flags
>   
>   OpenZFS uses feature flags instead of a zpool version number to track
>   features since the split from Oracle. In addition to avoiding confusion
>   on ZFS vs OpenZFS version numbers, this also allows features to be added
>   to different operating systems that use OpenZFS in different order.
>   
>   The previous zfs boot code (gptzfsboot) and loader (zfsloader) blindly
>   tries to read the pool, and if failed provided only a vague error message.
>   
>   With this change, both the boot code and loader check the MOS features
>   list in the ZFS label and compare it against the list of features that
>   the loader supports. If any unsupported feature is active, the pool is
>   not considered as a candidate for booting, and a helpful diagnostic
>   message is printed to the screen. Features that are merely enabled via
>   zpool upgrade, but not in use, do not block booting from the pool.
>   
>   Submitted by:	Toomas Soome <tsoome at me.com>
>   Reviewed by:	delphij, mav
>   Relnotes:	yes
>   Differential Revision:	https://reviews.freebsd.org/D6857

It is really great to get a helpful diagnostic message when an unsupported
feature is seen.  Thank you for that!

But I would prefer that the check is done on a filesystem level, not on a pool
level.  That is, I would like to be able to enable features that are not
supported by ZFS boot chain on a boot pool as long as I do not enable such
features on a boot filesystem.  E.g., the large blocks support could be one of
such features.

And, as I've said in another email, I really do not think that we should strive
to support all possible (non-essential) ZFS features in the ZFS boot chain.

-- 
Andriy Gapon


More information about the svn-src-all mailing list