From owner-svn-src-head@freebsd.org Mon Aug 22 14:16:11 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F518BC2E6C; Mon, 22 Aug 2016 14:16:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E949B140F; Mon, 22 Aug 2016 14:16:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA28441; Mon, 22 Aug 2016 17:16:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bbq1G-000PbF-SA; Mon, 22 Aug 2016 17:16:06 +0300 Subject: Re: svn commit: r303630 - in head/sys: boot/zfs cddl/boot/zfs To: Allan Jude , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, Toomas Soome References: <201608011937.u71JbhGD055117@repo.freebsd.org> <893dc513-69b4-ae9e-e3d3-2d2d02d04348@FreeBSD.org> <4139d778-9043-5f19-6f67-7f82ddfd9628@freebsd.org> From: Andriy Gapon Message-ID: <42238d8b-2a05-740f-62fb-d119f74d1958@FreeBSD.org> Date: Mon, 22 Aug 2016 17:15:10 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4139d778-9043-5f19-6f67-7f82ddfd9628@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 14:16:11 -0000 On 22/08/2016 16:54, Allan Jude wrote: > 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 >>> 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? I do not know any as easy way as just querying the feature flags. It's possible to query properties of a filesystem and reject any values that we do not support. Or we could do what we did before, that is, just try to read any data we need. But if we encounter something that we do not understand we can fail with a nice message (e.g. "unsupported checksum type foobar") instead of failing a "vague error message" like we did before. -- Andriy Gapon