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.

▲

zokier 17 hours ago | parent | next [-]

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.

▲

burnt-resistor 16 hours ago | parent | prev [-]

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.

0: https://www.freebsd.org/releases/13.0R/relnotes/

1: https://lists.freebsd.org/pipermail/freebsd-fs/2018-December...

▲

guipsp 16 hours ago | parent [-]

The link you posted explains exactly why they threw it away. You may disagree, but the stakeholders did not.

	▲	burnt-resistor 14 hours ago \| parent [-]
		Yes, I know. And I know iXsystems folks too. If you want stable, battle-tested ZFS, Solaris is the only supportable option on Sun hardware like the good ol' (legacy) Thumper. OpenZFS isn't tested well enough and there's too much hype and religious zealotry around it. For person use, it's probably fine for some people but, at this point, semi alternatives such as xfs and btrfs [thanks to Meta] have billions more hours of production usage.