Re: FreeBSD 13.2R and OpenZFS bug #15933
- Reply: David Christensen : "Re: FreeBSD 13.2R and OpenZFS bug #15933"
- Reply: tetrosalame : "Re: FreeBSD 13.2R and OpenZFS bug #15933"
- Reply: Daniel Tameling : "Re: FreeBSD 13.2R and OpenZFS bug #15933"
- In reply to: David Christensen : "FreeBSD 13.2R and OpenZFS bug #15933"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 29 Feb 2024 02:08:14 UTC
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