Honest question. As an end user that uses Windows and Linux and does not uses ZFS, what I am missing?
* If the hard drive / SSD corrupted blocks, the corruption would be identified.
* Ditto blocks allow for self healing. Usually, this only applies to metadata, but if you set copies=2, you can get this on data too. It is a poor man’s RAID.
* ARC made the desktop environment very responsive since unlike the LRU cache, ARC resists cold cache effects from transient IO workloads.
* Transparent compression allowed me to store more on the laptop than otherwise possible.
* Snapshots and rollback allowed me to do risky experiments and undo them as if nothing happened.
* Backups were easy via send/receive of snapshots.
* If the battery dies while you are doing things, you can boot without any damage to the filesystem.
For other stuff, let that nerdy CorpIT handle your system.
Also snapshots are great regardless.
Every ZFS block pointer has room for 3 disk addresses; by default, the extras are used only for redundant metadata, but they can also be used for user data.
When you turn on ditto blocks for data (zfs set copies=2 rpool/foo), zfs can fix corruption even on single-drive systems at the cost of using double or triple the space. Note that (like compression), this only affects blocks written after the setting is in place, but (if you can pause writes to the filesystem) you can use zfs send|zfs recv to rewrite all blocks to ensure all blocks are redundant.
Windows has its own extended filesystem through Storage Spaces, with many ZFS features added as lesser used Storage Spaces options, especially when combined with ReFS.
Rot means changing bits without accessing those bits, and that's ~not possible with zfs, additionally you can enable check-summing IN the ARC (disabled by default), and with that you can say that ECC and "enterprise" quality hardware is even more important for non-ZFS systems.
>Correct data with a faulty checksum will be treated the same as incorrect data with a correct checksum.
There is no such thing as "correct" data, only a block with a correct checksum, if the checksum is not correct, the block is not ok.
No. Bad HDDs/SSDs or bad SATA cables/ports cause a lot more data corruption than bad RAM. And ZFS will correct these cases even without ECC memory. It's a myth that the data healing properties of ZFS are useless without ECC memory.
The key feature for me, which I miss, is the snapshotting integrated into the package manager.
ZFS allows snapshots more or less for free (due to copy on weite) including cron based snapshotting every 15 minutes. So if I did a mistake anywhere there was a way to recover.
And that integrated with the update manager and boot manager means that on an update a snapshot is created and during boot one can switch between states. Never had a broken update, but gave a good feeling.
On my home server I like the raid features and on Solaris it was nicely integrated with NFS etc so that one can easily create volumes and export them and set restrictions (max size etc.) on it.
some linux distros have that by default with btrfs. And usually it's a package install away if you're already on btrfs.
(I have never used dedup, but it's there if you want I guess)
Reading any file will tell you with 100% guarantee if it is corrupt or not.
Snapshots that you can `cd` into, so you can compare any prior version of your FS with the live version of your FS.
Block level compression.
Only possible if it was not corrupted in RAM before it was written to disk.
Using ECC memory is important, irrespective of ZFS.
MacOS also defaults to a non-portable FS for likely similar reasons, if one was being cynical.
Couple it with encrypted zfs send/receive for cross platform secure backups.