Re: FreeBSD 13.2R and OpenZFS bug #15933

I am replying on the thread with the corrected bug number -- David


On 2/27/24 19:12, Edward Sanford Sutton, III wrote:
> On 2/27/24 16:00, David Christensen wrote:
>> ... [since installing 12.1R] >> I have used freebsd-update(8) and pkg(8) exclusively to
>> install software, to update/ update the system, and to update/
>> upgrade the software packages.
> 
> That approach is fine, though on ZFS there are reports of major 
> freebsd-update upgrades taking unexpectedly long amounts of time.


Thank you for the reply.  :-)


Thankfully, I did not experience upgrade problems with FreeBSD RELEASE 
12.1 through 12.4-p9 (other than PEBKAC).


(To replace the 12.4R computer, I plan to do a fresh install of 13.2R on 
another computer, backup the data on the 12.4R computer, and restore the 
data on the 13.2R computer.  I will validate the data migration with 
mtree(8).)



>> Is there a way to determine the origin (e.g. Illumos, OpenZFS) and 
>> version of the ZFS code that is running in the kernel on the above 
>> computer other than downloading the source tarball and crawling the
>> code?
>> 
>> https://download.freebsd.org/ftp/releases/amd64/12.4-RELEASE/


I decompressed the FreeBSD 12.4R src.xz tarball and looked for clues. 
There is a lot of code.  Searching for "illumos" and "openzfs" proved 
interesting when comparing 12.4R and 13.2R:

     2024-02-28 16:44:23 dpchrist@samba 
~/unzipped/download.freebsd.org/ftp/releases/amd64/12.4-RELEASE/usr/src
     $ find . -name '*zfs*' | xargs grep -i illumos | wc
          196     608   15804

     2024-02-28 16:44:28 dpchrist@samba 
~/unzipped/download.freebsd.org/ftp/releases/amd64/12.4-RELEASE/usr/src
     $ find . -name '*zfs*' | xargs grep -i openzfs | wc
            0       0       0

     2024-02-28 17:20:27 dpchrist@samba 
~/unzipped/download.freebsd.org/ftp/releases/amd64/13.2-RELEASE/usr/src
     $ find . -name '*zfs*' | xargs grep -i illumos | wc
          142     479   18266

     2024-02-28 17:20:53 dpchrist@samba 
~/unzipped/download.freebsd.org/ftp/releases/amd64/13.2-RELEASE/usr/src
     $ find . -name '*zfs*' | xargs grep -i openzfs | wc
           86     576   10380


So, it appears FreeBSD 12.4R uses Illumos code and FreeBSD 13.2R uses 
OpenZFS code with some Illumos remnants.


Crawling the 12.4R code, I am unable to find anything that looks like an 
Illumos release number or identifier (?).  Looking at the Illumos GitHub 
page, it appears Illumos does not do releases (?):

     https://github.com/illumos/illumos-gate

     Releases
     No releases published


I assume Illumos practices confirmation management, but I am unable to 
correlate the Illumos ZFS code in FreeBSD 12.4R with the Illumos GitHub 
repository.


> You could read release notes or maybe follow feature support changes 
> that came along with the migration. I thought migration from Illumos
> to OpenZFS (ZoL initially based effort) happened at 13.


A case-insensitive search for "zfs" finds zero matching strings in the 
"Announcement" and "Release Notes" pages for 12.0R, 12.1R, 12.2R, 12.3R, 
or 12.4R:

     https://www.freebsd.org/releases/


>> I have been reading about OpenZFS data corruption bugs since
>> November 2023 and delaying upgrading this and my other FreeBSD
>> computers.  I thought I had found an solution with FreeBSD 13.2R:
>> 
>> https://lists.freebsd.org/archives/freebsd-questions/2024-February/004920.html
> 
> Block cloning was accused for being the source of the November 
> 2023(?) bug which was tracked back to unrelated code from before
> OpenZFS from before 2010. 12 was not immune to the November 2023 bug,
> but it was less likely to happen due to fewer tools having as
> advanced of filesystem API support; a patch was released before
> support for 12 was dropped which freebsd-update should apply if it
> hadn't happened yet (don't remember patch#).
>
>> But, another OpenZFS data corruption bug report was opened
>> yesterday for the current version of OpenZFS (2.2.3):
>> 
>> https://github.com/openzfs/zfs/issues/15933


OpenZFS bugs #15526 and #15933 appear to be integration bugs that 
involve the (Linux) kernel, GNU coreutils, and ZFS.  The test case 
involves setting up a Portage system for Go on Gentoo Linux (?) and 
examining files manually for zeroed holes where non-zero values should 
be.  I do not know if the test case can be run on FreeBSD, if there is a 
test case for these bugs on FreeBSD, or if the bugs do not apply to 
FreeBSD because the kernel is not Linux (?).


>> Does this new OpenZFS bug [#15933] affect FreeBSD 13.2R?
> 
> [#15933] mentions using block cloning which 13.2R does not include or 
> support on the base system. Though a pool may have that enabled, I 
> thought it was still disabled with a sysctl (that I hope never goes
> away even when 100% bug free; its important to be able to rewrite
> data on disk when desired). I am not sure if the bug is only produced
> when block cloning is enabled or if block cloning just brings out a
> different bug. Until the bug is properly 'debugged' or further
> diagnosed, it would be hard to say what systems reproduce the issue
> and under what conditions.


So, is my data safe on up-to-date FreeBSD 13.2R ZFS with native 
encryption disabled?


David