From nobody Wed Dec 15 01:35:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC6F018DF21B; Wed, 15 Dec 2021 01:35:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDHrR5dZRz3rqs; Wed, 15 Dec 2021 01:35:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x82b.google.com with SMTP id a2so20247131qtx.11; Tue, 14 Dec 2021 17:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I3fW6l17aDAte9QIALYZqmTDcZY061EroKnoKtRRKys=; b=ItQkVU9nBr7D81ANzbTUdLXBj2KL32OhlHjvb2KjXEn4Nen+uChms8fdP34vUn3Jnm BavmukxAd8weZ5vvh/if+UN/lISWnr8+6mJQqxfzSCiv5eqY9mkJgw2v3YtkT8c/oZMw ctYuCKsM6grnLlzN6+mt1KZI4SyAXhO7ub6aObCVJnxp/3QFiRvFRczHi0O5K05PhZMl q2pkYXFO7EOgsjva4MX0Zd5jW9b2ZCtBq8ojjoN7ARRSSwu2Qj/wek5UsqtYYEVS6nIz LMEAeb1OKyN++wyp8eAex8HO/Z/UIicWvr5XCQtXYG2gzAhYJwmUhuxH6DHWsKWMeiSK aG2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I3fW6l17aDAte9QIALYZqmTDcZY061EroKnoKtRRKys=; b=RSatShG8JNV9utlxbMPcS9pa8jvTM8KILs4QcGZG96BGzey1Be3ZhTuFKeAKUDohR4 8jL+IviBhPrwUhQpJUy67sHRfWFKudrc6oUWnRsrc5IJkF7JJMgn3g8FqzYSl06Xejtu muu7neGQ7NnEiLCFbuydowRTiu74eEMSGA3vCQE3/e3OlEyAnHlFfWbF2P6U+av/W+E3 kbez5SZz7QgcGDE6Ctuj+bl9RNFkNUeq9ATMNI8Nn0UQhAovGjKLQS1Esy4E+2FWoFdl CYT4+vNy0nKH+pZK64qT7ddvMruPq617pyFVGvAcaqsriI2caICXnDF84DVICOnG+Ikz 5ACA== X-Gm-Message-State: AOAM532eN4Xqyrsbf34xnoiD/qTUFpKjujp1pydio5ZvgKuHyJfygEPb mgmy0mtIyQ+e61lEjldu88YeNv5tRvs= X-Google-Smtp-Source: ABdhPJyrFtM97aMI5JqfcMGbFO0rcXF6XSxpTImrdNabyGIDJfTwJf7M1Xbc7fYDI+aclTl1+QEuwQ== X-Received: by 2002:ac8:5881:: with SMTP id t1mr10006946qta.414.1639532150701; Tue, 14 Dec 2021 17:35:50 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id d6sm383981qtq.15.2021.12.14.17.35.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 17:35:50 -0800 (PST) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status To: Mark Millard Cc: freebsd-current , FreeBSD-STABLE Mailing List References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> From: Alexander Motin Message-ID: Date: Tue, 14 Dec 2021 20:35:49 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDHrR5dZRz3rqs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 14.12.2021 20:21, Mark Millard wrote: > I presume that because of FreeBSD's releng/13.0 and stable/13 (and > releng/13.? futures) that: > > /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd > > will never have edonr added to the file. Sound right? FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release branch. It is still updated periodically, but primarily with bug fixes. > Is there going to be a /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* > that has edonr as well (instead of using a openzfs-2.1-linux file for > such)? If yes, when does the file show up? Does main get drafts of the > file over time until there is a releng/14.0 that would have the final > version? FreeBSD main though tracks openzfs master branch, and as a moving target it has no compatibility definitions. I'd expect by the time of FreeBSD stable/14 branching there to be some new openzfs branch it could switch to, but so far AFAIK there were no specific announcements yet. And enabled edonr is a step toward not differentiating FreeBSD and Linux compatibility settings any more. >> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote: >>> I just noticed that main reports that my pools were created >>> implicitly matching openzfs-2.1-freebsd (and without >>> an explicit compatibility assignment) but, under main, zpool >>> import and zpool status for those pools report a new, disabled >>> feature. Turns out the issue matches what the diff below shows >>> as present for openzfs-2.1-linux but not for >>> openzfs-2.1-freebsd : >>> >>> # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* >>> --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 21:23:21.573542000 -0800 >>> +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 21:23:21.581738000 -0800 >>> @@ -1,4 +1,4 @@ >>> -# Features supported by OpenZFS 2.1 on FreeBSD >>> +# Features supported by OpenZFS 2.1 on Linux >>> allocation_classes >>> async_destroy >>> bookmark_v2 >>> @@ -7,6 +7,7 @@ >>> device_rebuild >>> device_removal >>> draid >>> +edonr >>> embedded_data >>> empty_bpobj >>> enabled_txg >>> >>> So I've taken to updating my existing zpool's via: >>> >>> zpool set compatibility=openzfs-2.1-freebsd NAME >>> >>> because I use them under releng/13 and stable/13 and main >>> and do not want edonr accidentally enabled. >>> >>> It is not obvious to me if edonr being present for main >>> is deliberate or not. >>> >>> For reference: >>> >>> # grep edonr /usr/share/zfs/compatibility.d/* >>> /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr >>> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr >>> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr >>> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr >>> /usr/share/zfs/compatibility.d/zol-0.7:edonr >>> /usr/share/zfs/compatibility.d/zol-0.8:edonr >>> >>> I happened to do this activity in a aarch64 context, in >>> case that matters. >> >> > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > -- Alexander Motin