openzfs VS zfs

I've used OpenZFS on OSX (https://github.com/openzfsonosx/openzfs#readme) and it's been better to me for cross-os drive sharing than NTFS or UFS, despite their warnings about using it on USB devices

I hear you about a ZFS root partition, though

Maybe OpenZFS but you need to know what you're doing, my advice is to use a VM to access the EXT4 partition then use the VM to transfer data, use a friendlier' FS like exFAT/FAT32 or use a network storage protocol like SMB/NFS etc. (that needs an additional system like a pi4 or something.)

This sounds great, but I would like them to see them fix bugs first, like this 6yr old one, with over 160 comments: https://github.com/openzfs/zfs/issues/9130 Every new feature, esp a complex one like this, creates a potentially huge amount of new bugs. Love ZFS, but would never run it without backups. Haven’t had data lose, but needed to restore from backups to get around constant panics.

It is safe to delete the second one. Even if it is not deleted, it will never be executed.

What is problematic is when they remove something like memset() right before a free operation, when the memset() is needed for security purposes. There are ways of forcing them to retain the memset(), such as using functions designed not to be optimized out, such as explicit_bzero(). You can see how we took care of this problem in OpenZFS here:

https://github.com/openzfs/zfs/pull/14544

My personal recommendation is to use secure string functions unless you can prove that you will never overrun the buffer, like what was done here:

https://github.com/openzfs/zfs/blob/master/etc/systemd/syste...

In particular, strcmp() implicitly is safe because one of the arguments is a constant string (and the buffer can be assumed to be at least as long as the constant string), while strcat() is safe because it is appending constant strings, such that the longest string that it can produce is known to always be smaller than the buffer length.

Nice catch. I had goofed by omitting optimization when checking this.

That said, this brings me to my original reason for checking this, which is to say that it did not use a cmov instruction to eliminate unnecessary branching from the loop, so it is probably slower than a binary search that does:

https://en.algorithmica.org/hpc/data-structures/binary-searc...

That had been the entire motivation behind this commit to OpenZFS:

https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...

It should be possible to adapt this to benchmark both the inlined bsearch() against an implementation designed to encourage the compiler to emit a conditional move to skip a branch to see which is faster:

https://github.com/scandum/binary_search

My guess is the cmov version will win.

For long term storage, prefer hard drives (careful about CMR vs SMR)

If you have specific random IO high performance needs, you can either

- get a SLC drive like https://news.solidigm.com/en-WW/230095-introducing-the-solid...

- make one yourself by hacking the firmware: https://news.ycombinator.com/item?id=40405578

Be careful when you use something "exotic", and do not trust drives that are too recent to be fully tested: I learned my lesson for M2 2230 drives https://www.reddit.com/r/zfs/comments/17pztue/warning_you_ma... which seems validated by the large numbers of similar experiences like https://github.com/openzfs/zfs/discussions/14793

I am #4 here:

https://github.com/openzfs/zfs/graphs/contributors

I would have preferred to see what the LLM would generate without assistance, rather than make a wish list, but since you asked:

* Explanations of how each sub-component is organized and works would be useful.