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

[Allan Jude]

On 2016-08-22 04:21, Andriy Gapon wrote:
> 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.

This was my though originally, but it is not as easy to tell if a
filesystem has ever used a feature. For pool wide, it is just a property.

Do you know of an easy way to get this information for a specific file
system?

> 
> 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.
> 



-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20160822/576ec74e/attachment.sig>