I wrote something down on Github and would love to hear your feedback.
Last edited:
The problem with RAIDZ or why you probably won't get the storage efficiency you think you will get
- Thread starter IsThisThingOn
- Start date
too interesting to be ignored and nice explained, thanks! i will read and test with time
Last edited:
I am only seeing this now. Gave it a quick glance. Nice writeup and tests!
We discuss this (with fewer examples) in the admin guide as well: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_raid_considerations
We discuss this (with fewer examples) in the admin guide as well: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_raid_considerations
nice writeup, but I humbly suggest that this isn't a representation of a "problem" as the subject suggests. What you've done is quantify how zfs utilizes vdevs to provide usable storage- no more, no less, user expectation notwithstanding.
Thank you guys for your feedback! Glad that you seem to like it.
I personally think that most mirror proponents focus to much on performance. That leads beginners to believe, that because they don’t need the performance, they will get away with the increased efficiency. They would say stuff like „I only run 5 VMs“ or „only Plex files“ but don’t understand how big of a role geometry plays or what advantages a dataset could offer to them.
So my main point is, that you choose RAIDZ with all its disadvantages over mirror for storage efficiency but unless you really know what you are doing and have a suiting workload, you won’t even get that!
That to me is the „problem“ with RAIDZ.
I personally think that most mirror proponents focus to much on performance. That leads beginners to believe, that because they don’t need the performance, they will get away with the increased efficiency. They would say stuff like „I only run 5 VMs“ or „only Plex files“ but don’t understand how big of a role geometry plays or what advantages a dataset could offer to them.
So my main point is, that you choose RAIDZ with all its disadvantages over mirror for storage efficiency but unless you really know what you are doing and have a suiting workload, you won’t even get that!
That to me is the „problem“ with RAIDZ.
the problem with RAIDz is that it has the bare minimum of fault tolerance, and is one drive fault away from operating without a safety net. Any "advantages" it has are effectively overshadowed.
Parity raid is not good for virtualization payloads for many reasons; raidz2/z3 have use cases for bulk storage.
Well, the same could be said for mirror. There is 3 way mirror and RAIDZ2-3 if you want to survive multiple drive failures.
But I agree on that RAIDZ is not good for virtualisation for many reasons and the only advantage of RAIDZ (Storage efficiency) is sometimes even not true.
But I agree on that RAIDZ is not good for virtualisation for many reasons and the only advantage of RAIDZ (Storage efficiency) is sometimes even not true.
yes, but not to the same extent. a missing member on a raidz vdev in endangering the whole vdev. ANY other failure will take the whole volume down. A missing drive on a striped mirror will endanger only the one vdev in the group, which means ONLY the failure of the surviving partner will take the array down and not any other drive in the array.
the purpose of disk aggregation is not to eliminate risk- this is not possible, but to minimize and allow for mitigation. A striped mirror, for example, will resilver a lot faster than a raidz volume. In a large enough array, you can stripe across multiple parity raid vdevs and get the best of all worlds, but that would require a lot of disks to be effective- and at that point you may be looking to move your failure domain up to the host level and move to ceph anyway.
-edit- I noticed you said it could be said for a single vdev mirror; while true, you dont have any options with only two drives.
Last edited: