From nobody Tue Apr 18 23:55:56 2023 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 4Q1LRL4X73z45t0B for ; Tue, 18 Apr 2023 23:56:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q1LRK3GzKz4H0R for ; Tue, 18 Apr 2023 23:56:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681862171; bh=NB1fltZ5kp32UB4/jd8DTRcsgcnvoTjB6TTBeZqpx9I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I9qqirZ1ozyPIa+7oLHJifYKpEqeV+FDJVYs3c2ohyNuaVDj1k/fGafyzHhosRUuvXl1MgiJkpDXLgkFz/OEoszIxoHlnnMCp5Ovg0YvK2DJZeHtPPPAg0XDQ7sp5eYmHfOdd4YCzBCap2jRdrB/tKNxCi690rrCx0hUwzTHEG+qUuE3ROlfnrUe5fNsxA59znfhDXIkydn4UZ6coGYU9j7sh/A0jNmwteebKLWP0He+qShMKyUZcKokI2LuZRgN4w+F7JiRA8iJ4R6EVoIfYJYVYzg8bb6chTeIvo/PD67O50bz5Rnr9klI0z++A4+wIdrf8lgG2RaPxI9mh7lRIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681862171; bh=fXndzEeYOU+d59tlijJU70pwB0QBiTHCDhIaCMlPa6D=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uiGeqnCOKyCnPOjOsnfgXMXZIB96m71YLgn/jEhsG9ps3WX5iwdfP5I2HL7zhxf7AVajzZdbciidHMX9SKjOqmzGe80TXFZvrAPt+YUZEHqeYqDdUmVVr8U3Fq449yn1pDc6zDZadSc4NLHxCeYX4f7g5a/E/o7WK/QuXdOI4jqXtCBPRAEu8JblCCSSLOxZdRs1AGgZCIpyO3pbbALhQdTda5e21+5wkT/bVoHEHoxGlbz8qEmNfyQb8yi2z8uw+67f8s94CJEJjmP6KnPy7T4+tM1cg+OjSwGeuj3sf5Lcf2kLoOWhbOn8LElVyLbl7Bwxia6xjO9VCyY5W3HgkA== X-YMail-OSG: ecA0eTgVM1mL2gWYvo5vfWKAo9oqcgoe6zwwQKOg5YqSRx38fi7kPF3WJgJGs75 AR8.ofmjL4il8agjs0UMJ3K_ek11M.OLGv.WjjfKA4iOUQgUoPpfctQ_KcXMI_f16a5YPFh12rGW tAQVw31BNM7YCs00nB05DXSoL7uKjFZ7ib.ctSjEhDnprUwmrHNCFvkRewUXWhz7ggINfouZsRfH rRQEwAaLE.M6TCo8PXUYKjuot7U0.ezYPKyv1jQ8hTsXLu5LwyQowG6JIuq.lygG2afzyWc23IqR qS7KrTxGB7sSvNzuFKkJoY50NcDzY1tFFDPzwGtcpuu4Hz89r5t4LiKPn7k4Npx1OBZYVdjLPz2x YuOUSrXeiGWIUeW6lZqEHTXIA9dNlPY0cyGtqNXuDvOzqQ0nw3MJ0bY_Gzxcx0StLfHpTskMmW93 PA4o5vlPvx0QovofHynK5U1emAaIlbWF4JWCq9MQ.ztbBa3yn8VQeG4bvjGpjzJNRlkzqc725nyF Qvvs_vQR5giXwHS555vXN_CyVZ_Agsoa0cq3NGKKbtBIkFF5myT6ZidF0JYGAvFVffNu.p3FngVj EbE7BLJbSXemwMwSSXmnG6KlSetDDMuwBRzBGXQ97nyxjk3F0q4nP6VlcQvzhv0vP2ieohKU4q1G TdrshFAVf13F2oLUYEgMNj4D1O5XY96ucnlc.l6xLLLLmoON.OUUv2jnLMMK0LwRN4vXi9Gv9aHd ujFr.MdpJzTfLiiHuVjmV2vW_2ccgWNqGCMYzf04iJ734GJe2vkSqhQbMmZqT7081oddU3luZkqD HAABeysho1WqOjh2B1NUROAYXBCCJdCmvMk60oUwgNM4Ft7r9SowTPheTjFNefe6p7ukOXUAtdyS nnb0rxorMfvVWmxkKoGYEdrQ8PFIhsAqHAA7zip6cZIwMqLMICS25D7QJ3l.XadfspHEW.XSyde9 Cz_SUMj5.iPmdVqY7nLIpw5IKgRr1PQsWm6zEXVTxmEXmZQdU407XNta7BoJEq63wuM2jAz2wgPY taJHh0to2ZsKVZ9PTwR_es07JJ87uHwlXSjss3fYu715nsCZ1jY6391Jo.yu3pG_6AxwkZzRbbrH O73hJvMkyML5cgqWSlPJXqfm0zr.NGmx4i2ff1Jdk2Vtkj68S56BJQ3bT3jCtVj.LdRZo.0LBIjR 3td3bqOUE8uwgPH.mgahyxzueTA_vWSniTXzNHqvFT0YdmQClSmwD7dofPCosAIqvLfEUuIEq6.v P_r0I1Naudk6Ge5ZzZ9kuM7WJ3_x2U6Od5luCDSmSrqvAaeHCGK29FfQ3nAIaqo4dEBSCf188an_ lRTV9qikz9nzfMV_pqkM6oKSDI95LbhqSvdJ6ZFd48b2o8O4knUi80p9VOoeqvDM7FGuwBouBjJ7 6uELeAuB1N2Qa63f5USvNJSGuEaw1K7Ve63nq0XTtT1oGOCJIYkSrlXDKTPZLNADek6S7wgy8rHK ABEMWyntM0YSl347GSd4wrAQQ6fiJlYjuaLiV_Az0vETQOkZSjxxb_zQBffbMXYTAnoo0uElaaBo 6AiNSxreK9D4saPTKf0JDU1Ixe8EkIj6erL3t51Nklexy5cHvp1DbpjeePgjml.8P95VUnpuMhl. 64Ncia55IGHaH.RTBzV.9NB1wpIvOzrJ9i0Hd5Gu5csBFrWWdrDhm2qfw1jYEsFbuWTk.xOdd_Ck DVLmf5O7VZ6dgaqrgZjhwiliydlRgXZkY5s1NhVsLiirgVP8HkrrUp8Kfugw03DOxtbg9tqjOA37 7WodXI_rN8KWf7bko0pAcdHUgVy6CuOGvyXayeFLe5rpO9OaRc_od4HqsdfAar4wfVTOaS_Za3oD ehaPtM4HLmk1YFcFNIMGXaU._IGBSbpefyWjIW.Ss7vZpKe0JuN_ofL_vmEiGY1S3D07BBBitWis YtkWDIlNodL3WOauYmjNZWVVoPPtXv_T8xwbVfT.Gl0VXSGlUcYYSmgtpFw_4IL09hVs9xVsg2cJ S1KoDGAzygVpxLNjOFksNT4QxqF892GHoli5Qg_h7L41XAAXc5mvQh3eiymTzkciZiyNsRO0ny.y kiWO79SJ5JOGDR5SxbgwhVmsKDY3IpvOBY.DUGHA1_RsfUycRMyQnBkOewfc_praSOmxyCvQ1CF5 fgR1uVo88R49jOwpuif4Xqt0ylaoU8Oh6IWoGxEU.O9mxtXmSb4YOUmPMdCXvowEKkNXlr89bb13 HdPqTZUCkAGBZqfoUCzmdF3cIMNIOpks4XIFwt3WkSnYVJsqAjb9yrUhPzLjwdjv8JE1KB9hCquW yu1t1kA-- X-Sonic-MF: X-Sonic-ID: 4e0e9d0a-0176-4df4-9913-681f2a24736b Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Apr 2023 23:56:11 +0000 Received: by hermes--production-gq1-546798879c-8jjxz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4715eb63546015f84a72ead8d556e8a2; Tue, 18 Apr 2023 23:56:06 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 From: Mark Millard In-Reply-To: <8fecc2d8c2eb471ec70122a7d5fb249d@mail.yourbox.net> Date: Tue, 18 Apr 2023 16:55:56 -0700 Cc: Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <9EA4F05D-F9BB-41DC-9C57-16DFEE61CC4F@yahoo.com> References: <963B0620-5342-4EC3-AA54-52DDD70D9E3D.ref@yahoo.com> <963B0620-5342-4EC3-AA54-52DDD70D9E3D@yahoo.com> <8fecc2d8c2eb471ec70122a7d5fb249d@mail.yourbox.net> To: =?utf-8?B?Sm9zw6kgUMOpcmV6?= X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Q1LRK3GzKz4H0R X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Apr 18, 2023, at 15:02, Jos=C3=A9 P=C3=A9rez wrote: > El 2023-04-18 21:37, Mark Millard escribi=C3=B3: >>> In this case it does because the value is "active". If it's = "enabled" >>> you do not need to do anything. >> Well, if block_cloning is disabled it would not become active. > [...] >> So, in progressing past the vintage that corrupt zfs data, >> one could end up with block_cloning enabled in the process. >=20 > You still have to willingly issue the command > zpool upgrade > so you might not just end up with the feature enabled by running this > or that kernel, that's why I suggested step 0: verify if you are the > worst case scenario before you begin. I was not really worried about the no-zpool-upgrade/disabled case. I was worried about "enabled" vs "active" as the transition enabled -> active is automatic based on activity. But there is overall disabled vs. enabled vs. active for the block_cloning feature so I mentioned all 3. >>> Boot in single user mode and check if your pool has block cloning in >>> use: >>> # zpool get feature@block_cloning zroot >>> NAME PROPERTY VALUE SOURCE >>> zroot feature@block_cloning active local >>> In this case it does because the value is "active". If it's = "enabled" >>> you do not need to do anything. >=20 > If you did not upgrade the pool, the feature would just not be there = and > the pool is sane (*). "Not being there" vs. "disabled" has some context to it. I worded based on the way my context shows things. My example context has: # zpool get all zroot | grep compat zroot compatibility openzfs-2.1-freebsd = local which explains the particular list of disabled features reported below. (It is a "never had zpool upgrade" context as well.) # zpool get all zroot | grep disabled zroot feature@edonr disabled = local zroot feature@zilsaxattr disabled = local zroot feature@head_errlog disabled = local zroot feature@blake3 disabled = local zroot feature@block_cloning disabled = local so "not be there" seems to mean "disabled" as zpool presents things based on compatibility. Just to see the command you listed fully but in my type of context: # zpool get feature@block_cloning zroot NAME PROPERTY VALUE SOURCE zroot feature@block_cloning disabled local # zpool version zfs-2.1.99-FreeBSD_g431083f75 zfs-kmod-2.1.99-FreeBSD_g431083f75 (Those are software versions, not properties of specific pools.) I'll note that I see: # zpool get feature@JUNKNAME zroot #=20 So features that the software does not have in its list of possibilities get an empty result. > unaffected_machine# zpool get feature@block_cloning zroot > unaffected_machine# That is the same sort of output as in my feature@JUNKNAME test above. It is not clear from what is presented that the context had block_cloning in its list of possibilities. In my normal environment (that still predates the import of the openzfs update), I get the same sort of result for feature@block_cloning as you show above. > As said, if the feature has been enabled but no calls to > copy_file_range() occurred, the pool is also sane. A the time but more activity can change the status because copy_file_range() could be called. So I expect that the following step is relvant to avoid ending up with block_cloning becoming active: QUOTE When in single user mode set compression property to "off" on any zfs=20 active dataset that has compression other than "off" and the sync=20 property to something other than "disabled". END QUOTE > To summarize: > no feature -> sane > feature "enabled" -> sane > feature "active" -> might not be sane >=20 > BR, >=20 > (*) as per this bug. =3D=3D=3D Mark Millard marklmi at yahoo.com