- Joined
- Mar 6, 2014
- Messages
- 9,554
There were SMB-related bugfixes mentioned in the release notes. (xattr removal failure)
-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum will now become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
Jailer
Not strong, but bad
- Joined
- Sep 12, 2014
- Messages
- 4,977
I think SMB bugs are a feature.
- Joined
- Nov 29, 2021
- Messages
- 60
It is https://www.truenas.com/docs/core/13.0/gettingstarted/corereleasenotes/#130-u6Sry, but I was unable to find the relase notes;
or.13.0 Release Notes
Highlights and change log for the current major version of TrueNAS CORE.www.truenas.com
I fixed the link. Thanks for reporteing.
- Joined
- May 28, 2011
- Messages
- 10,994
Boring is good to me. I'm not a fan of problems.
Last edited:
Major Samba updates will be in 13.1.... for any specific issue, identify the bug fix you need.
I have a question, 1. How do I update, and why does it ask me to save Secret Keys, and 2. I noticed a link that reads "Before updating, please read the release notes." and then takes me to talking about "Nightly" build updates. So is this a dev update? Or a full stable update that's ready for production?
- Joined
- Nov 25, 2013
- Messages
- 7,776
Kevin Horton
Guru
- Joined
- Dec 2, 2015
- Messages
- 730
But, if I click the link for the release notes from the System / Update in the TrueNAS-13.0-U5.3 UI, the link takes me to a Nightly Version Notes page
Juan Manuel Palacios
Contributor
- Joined
- May 29, 2017
- Messages
- 146
Does anyone know if the ZFS bundled in this new TrueNAS Core release is 2.2.0? Is it affected by this bug? https://github.com/openzfs/zfs/issues/15526 (which was worked around in 2.2.1, https://github.com/openzfs/zfs/pull/15529).
Thank you,
Thank you,
winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,641
It’s on 2.1.13.
Juan Manuel Palacios
Contributor
- Joined
- May 29, 2017
- Messages
- 146
Awesome, thank you for that info!
winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,641
Man, that's a really nasty bug. Now I'm worried...
Apparently, it's been reproduced even with Open ZFS 2.1.13. So it doesn't only affect 2.2.0. Block-cloning, while not the cause of the problem itself, seems to trigger the conditions for the bug to more likely occur. (It still occurs in 2.1.13, which lacks block-cloning.)
The "fix" for 2.2.1 is simply to disable the Block-Reference Table by default. (It's more like a temporary safeguard until they can truly fix the bug.)
There's a lot of discussion going on in that bug report. (Still ongoing, as of an hour ago.) It makes me feel uneasy that using a stable version of ZFS can silently corrupt your data.
They believe it might be the way coreutils works with ZFS. Yet, it was reproduced on FreeBSD 14.
What the heck happened?
winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,641
A "reproducer" script was created in the discussion by Tony Hunter.
You can test it yourself in a temporary, junk folder. It's meant to be run in parallel (4 at once) to try to trigger the bug.
Here is his post for reference:
github.com
Apparently, someone was able to consistently reproduce the bug on TrueNAS Core 13.0-U5.3, ZFS 2.1.11.
I might spin this up myself. Tomorrow might not be feasible though.
This type of bug in ZFS really worries me.
You can test it yourself in a temporary, junk folder. It's meant to be run in parallel (4 at once) to try to trigger the bug.
Here is his post for reference:
some copied files are corrupted (chunks replaced by zeros) · Issue #15526 · openzfs/zfs
System information Type Version/Name Distribution Name Gentoo Distribution Version (rolling) Kernel Version 6.5.11 Architecture amd64 OpenZFS Version 2.2.0 Reference https://bugs.gentoo.org/917224 ...
github.com
Apparently, someone was able to consistently reproduce the bug on TrueNAS Core 13.0-U5.3, ZFS 2.1.11.
I might spin this up myself. Tomorrow might not be feasible though.
This type of bug in ZFS really worries me.
A "reproducer" script was created in the discussion by Tony Hunter.
You can test it yourself in a temporary, junk folder. It's meant to be run in parallel (4 at once) to try to trigger the bug.
Here is his post for reference:
some copied files are corrupted (chunks replaced by zeros) · Issue #15526 · openzfs/zfs
System information Type Version/Name Distribution Name Gentoo Distribution Version (rolling) Kernel Version 6.5.11 Architecture amd64 OpenZFS Version 2.2.0 Reference https://bugs.gentoo.org/917224 ...
Apparently, someone was able to consistently reproduce the bug on TrueNAS Core 13.0-U5.3, ZFS 2.1.11.
I might spin this up myself. Tomorrow might not be feasible though.
This type of bug in ZFS really worries me.
We'll investigate.. but so far we don't have confirmation of a real issue in TrueNAS.
- Joined
- Nov 25, 2013
- Messages
- 7,776
Yes. That's a bug.
Juan Manuel Palacios
Contributor
- Joined
- May 29, 2017
- Messages
- 146
Yes, it is a very nasty bug, and all of a sudden I'm now also scared for my data, after having read to the current end of the comments in that Github issue, because my system matches one that reproduced the problem (zfs-2.1.11-1).A "reproducer" script was created in the discussion by Tony Hunter.
You can test it yourself in a temporary, junk folder. It's meant to be run in parallel (4 at once) to try to trigger the bug.
Here is his post for reference:
some copied files are corrupted (chunks replaced by zeros) · Issue #15526 · openzfs/zfs
System information Type Version/Name Distribution Name Gentoo Distribution Version (rolling) Kernel Version 6.5.11 Architecture amd64 OpenZFS Version 2.2.0 Reference https://bugs.gentoo.org/917224 ...
Apparently, someone was able to consistently reproduce the bug on TrueNAS Core 13.0-U5.3, ZFS 2.1.11.
I might spin this up myself. Tomorrow might not be feasible though.
This type of bug in ZFS really worries me.
Is there any potential mitigation you'd recommend at this point? ZFS developers on that issue talk about setting zfs_dmu_offset_next_sync to 0 as their current best guess to avoid the problem entirely, and I'm guessing on FreeBSD that translates into setting the vfs.zfs.dmu_offset_next_sync sysctl variable to 0.
Is that correct? Is that something you recommend? Or is there a reason we may not want to mess with that sysctl variable?
Thank you in advance!
