rcombs

XFS, Btrfs, and ZFS both offer checksumming (for metadata only on XFS; also for file contents on Btrfs and ZFS), but currently Unraid doesn't provide a way to actually recover from a detected checksum error. In theory, it could do better at this: when a checksum error occurs on an array drive, the affected block could be reconstructed from parity and re-written automatically. The parity-check could also do better than it does currently (to my understanding): if a parity error is detected, Unraid could decide which drive's data is incorrect by considering whether the corresponding disk block's checksum is correct on each data drive. Currently, as far as I'm aware, parity-check always trusts the data drives and rewrites parity on errors. This would require some tighter integration between the array and the filesystem, but I think the benefits would be worthwhile. If this was implemented, we'd be able to get one of the critical benefits of a ZFS pool (automatic protection against data errors) while still maintaining the flexibility of the Unraid array (easy gradual expansion, mixed drive sizes, etc).

Sure, but that's individual drives in an unRAID array, not a RAIDZ setup. It's a reasonable choice for some people, certainly, but it doesn't give the benefits of RAIDZ (self-healing, striping performance, etc). I want to have my cake and eat it too.

This is less of a feature request and more of a "what are the odds that this ever happens", but here goes: I'm sure plenty of unRAID users love the ability to upgrade drive slots piecemeal, and run an array with multiple different drive sizes. Is there any chance of that being supported in ZFS at some point? If not, could unRAID work around that with a solution like in this example: Say you have a 4TB, a 6TB, an 8TB, a 12TB, and 3 16TB drives, and you want 2-drive parity So you create a 4TB partition on each drive, then a 2TB drive on the 6TB-and-up ones, another 2TB on the 8+s, a 4TB on the 12+s, and another 4TB on each of the 16s You combine each set of partitions into a raidz2 vdev (of which you have 5 total, one for each partition on the largest drives), all within a single zpool I've seen this approach discussed in a few places before, and a lot of people seem to reflexively reject it, but I'm not entirely sure why? There'd certainly be a lot of complexity in the management/UI tooling for this, but I don't think any of the problems are unsurmountable. In theory, it could allow for all the benefits of ZFS while still retaining the upgrade-friendliness of classic unRAID.