Glen Barber, member of the FreeBSD Project as the FreeBSD Release Engineering Lead, pushed the following commit about his struggles with alchohol abuse.

https://github.com/freebsd/freebsd-doc/commit/c8dd24d3c66ac65b30a295dca885e4bbb83f6b17
Glen Barber, member of the FreeBSD Project as the FreeBSD Release Engineering Lead, pushed the following commit about his struggles with alchohol abuse.

https://github.com/freebsd/freebsd-doc/commit/c8dd24d3c66ac65b30a295dca885e4bbb83f6b17
It gets even worse. Trust no one folks …

So this ZFS data corruption issue caused me being insecure about my data safety and to check my system for bit rot with btrfs scrubbing…
Scrub is a pass over all filesystem data and metadata and verifying the checksums. Basically, it reads all data on the disk, recomputes its checksum, and compares the recomputed checksum to the stored one. When the stored and recomputed checksums don’t match, the system knows there’s corruption.



Tests were performed on a 64 core AMD EPYC with 192 GB of RAM.




Ed Maste, the Director of Project Development for The FreeBSD Foundation, sent the following email in the freebsd-stable mailing list, regarding a new ZFS issue. It appears that it affects earlier versions of OpenZFS and it is not related to block cloning.

Dear FreeBSD community,
We want to bring your attention to a potential data corruption issue
affecting multiple versions of OpenZFS. It was initially reported
against OpenZFS 2.2.0 but also affects earlier and later versions.This issue can be reproduced with targeted effort but it has not been
observed frequently in real-world scenarios. This issue is not related
to block cloning, although it is possible that enabling block cloning
increases the probability of encountering the issue.It is unclear if the issue is reproducible on the version of ZFS in
FreeBSD 12.4.A short term workaround is available for FreeBSD 14.0 and 13.2 by
setting the vfs.zfs.dmu_offset_next_sync sysctl to 0:echo vfs.zfs.dmu_offset_next_sync=0 >> /etc/sysctl.conf
sysctl vfs.zfs.dmu_offset_next_sync=0
The workaround may result in inaccurate reporting of file holes in
sparse files, reintroducing OpenZFS issue 6958[1]. See the ZFS(4) man
page for more information on this setting.The workaround does not deterministically prevent the issue but does
drastically reduce the likelihood of encountering it.For more information, see OpenZFS issue 15526[2] and OpenZFS pull
request 15571[3]. FreeBSD bug report PR 275308[4] is open to track the
FreeBSD erratum update which will bring in the fix, after it is
committed to OpenZFS. Please check the FreeBSD PR regularly if you are
looking for details on the timeline of the FreeBSD erratum update.We want to assure the FreeBSD community that we are actively monitoring the situation. Thank you for your understanding and continued support.
<https://lists.freebsd.org/archives/freebsd-stable/2023-November/001726.html>
So Microsoft introduced Excel Python in August. A useful feature that could help tremendously with data processing and research.
“On September 9, 1947, the team at Harvard University in Cambridge, Massachusetts, found that their computer, the Mark II, was delivering consistent errors. When they opened the computer’s hardware, they found … a moth.”

https://education.nationalgeographic.org/resource/worlds-first-computer-bug/