This, fsync() data corruption, BitterFS issues, lack of Audit on io_uring, triplicated EXT2,3,4 code bases. For the past 20 years, every time I consider moving mission critical data from FreeBSD/ZFS something like this pops up.
Personally I think these problems are a sign that posix fs/io apis are just not that good. Or rather they have been stretched and extended way past their original intent/design. Stuff like zenfs give interesting glimpse of what could be.
FreeBSD 13+ threw away their faithful adaptation of production-proven code for OpenZFS (ZoL).[0,1] I refuse to use OpenZFS (ZoL) because a RHEL file server self-corrupted, wouldn't mount rw any longer, and ZoL shrugged it off without any resolution except "buy more drives and start over".
Overall, there's grossly insufficient comprehensive testing tools, techniques, and culture in FOSS (FreeBSD, Linux, and most projects) rely upon informal/under-documented, ad-hoc, meat-based scream testing rather than proper, formal verification of correctness. Although no one ever said high-confidence software engineering was easy, it's essential to avoid entire classes of CVEs and unexpected operation bugs.
Many mistakenly believe that FreeBSD took the ZFS implementation from Linux. It's not true, and it never was. OpenZFS is the result of merging code from illumos, Linux, and FreeBSD.
zokier|4 months ago
burnt-resistor|4 months ago
Overall, there's grossly insufficient comprehensive testing tools, techniques, and culture in FOSS (FreeBSD, Linux, and most projects) rely upon informal/under-documented, ad-hoc, meat-based scream testing rather than proper, formal verification of correctness. Although no one ever said high-confidence software engineering was easy, it's essential to avoid entire classes of CVEs and unexpected operation bugs.
0: https://www.freebsd.org/releases/13.0R/relnotes/
1: https://lists.freebsd.org/pipermail/freebsd-fs/2018-December...
guipsp|4 months ago
anime_snail|4 months ago