While looking at a forum thread about RAID-0, I realized that people still don’t understand the difference between ZFS Striping and classical RAID-0. So I responded;
This led me to think that perhaps OpenZFS should add a RAID-Z0 vDev type to make a more classical RAID-0 implementation. The ZFS data would be striped across the width of the RAID-Z0 vDev, based on how much data needed to be written. And if full width contiguous blocks were available. That “stripe” would have only 1 checksum and be in the same compression, encryption and de-duplication block.
This is different from normal ZFS Striping on non-redundant devices. Normal ZFS Striping would write a complete ZFS block to a single non-redundant device, (singular), along with 1 copy of the standard metadata. (Other metadata would be written too, with the extra copies to other vDevs.)
So, should OpenZFS modify RAID-Zx code to support no-Parity to simulate RAID-0 for those that want it?
And of course, accept the risk?
It would be expected that RAID-Zx expansion should also apply to RAID-0…
Of course, I could be wrong about ZFS Striping…
Note the date, it’s is not the first day of next month… though you don’t have to take this seriously.
What would be the use case?
It can’t be data safety.
If it’s performance, ZFS is probably not the best starting point: Genuine RAID 0 may have an edge—and would use less RAM.
Content delivery servers, where the content has a master copy elsewhere. If one site goes down, their is probably another available for the use. Think video streaming service, like NF, AZ, and YT. Or educational videos for a major college system, (like California, which has a significant portion of the population of the US).
In someways, the Read Only part of the system. Another ZFS pool could be used for the indexes, support files, etc… that requires R/W access.
But, @etorix is right, a ZFS based NAS might not be the best choice for such a system, if it needs performance above all else.
However, there is one point to make about failures. Many failures would be a sector(s) of a storage device. A full storage device failure, (NVMe, SSD, HDD), would of course cause full pool failure. But, a sector failure would only affect a single file. (Remember, ZFS has redundant Metadata.) Either read access or scrub would detect sector failures, and allow the application software to restore that file from the master copy.
To be clear, this is exactly my use case for my miniature media server at home. It, however, uses normal ZFS Striping of the 2 storage devices, laptop HDD and mSATA SSD.
I don’t see the need for a RAID-Z0, that makes no sense, well to me, and really does not live up to the purpose (if I understand correctly) of what ZFS is doing, protecting the data through various means. Even a ZFS Stripe has parity although it does not protect against total drive failure. But at least your data would not be corrupt if you can access it and you had some bad sectors.
It was interesting reading this thread and the other one @Arwen referenced.
If I understand correctly, the benefit of raidz0 over stripe would be to reduce the metadata overhead, for large files which would be spread over all drives anyway.
Is it worth the effort?
I’d also think that large storage servers with lots of disks would have a non-insignificatnt probability of suffering a complete drive failure, in which case the non-redundant array would be lost, forcing to pull back the master copy of everything to rebuild.
Reducing the metadata overhead is only part of it. The read would automatically span all the columns of the RAID-Z0, that are part of that ZFS block. Just like RAID-Z1/2/3. So, while writes may not have much increased speed over normal ZFS Stripe writing, reads could potentially have much higher speed.
As for effort, most likely no, it would not be worth the effort. Only is specialized cases would benefit from the RAID-Z0 concept.
Well, it is not just disk failure. Yes, a full disk failure would cause pool loss. So a careful design would be needed on what needed redundancy and what needed the higher performance.
In my opinion, storage device sector failures are more likely. Those would only affect files, (due to metadata redundancy). And could be dealt with much more easily than full re-population.
Note that the use cases I postulated would likely not be the only ones. For example we have seen people here in the forums want temporary storage for video editing, or file downloading. They want speed, and claim they don’t need redundancy. With those being temporary, any pool loss due to a storage device complete failure, should only impact hours of work. Plus, no need to re-populate.
Last, I am not advocating for RAID-Z0. This is more of a thought exercise and discussion. Perhaps a Pie In The Sky discussion, if money was not a restriction.
