Le 5 janv. 10 à 17:49, Robert Milkowski a écrit :
On 05/01/2010 16:00, Roch wrote:That said, I truly am for a evolution for random read workloads. Raid-Z on 4K sectors is quite appealing. It means that small objects become nearly mirrored with good random read performance while large objects are stored efficiently.Have you got any benchmarks available (comparing 512B to 4K to classical RAID-5)?
Using 8K 'soft' sector prototype on an otherwise plain raid-z layout, we got 8X more random reads than with 512B sectors; as would be expected.
The problem is that while RAID-Z is really good for some workloads it is really bad for others.
The bigger sector makes raid-z like mirroring for small records. And so performance of raid-z will be very good and it's also space efficient for large objects.
Sometimes having L2ARC might effectively mitigate the problem but for some workloads it won't (due to the huge size of a working set). In such environments RAID-Z2 offers much worse performance then similarly configured NetApp (RAID-DP, same number of disk drives). If ZFS would provide another RAID-5/RAID-6 like protection but with different characteristics so writing to a pool would be slower but reading from it would be much faster (comparable to RAID-DP) some customers would be very happy.
Agreed.
Then maybe a new kind of cache device would be needed to buffer writes to NV storage to make writes faster (like "HW" arrays have been doing for years).
Writes are not the problem and we have log device to offload them. It's really about maintaining integrity of raid-5 type layout in the presence of bit-rot even if such
bit-rot occur within free space.
A possible *workaround* is to use SVM to set-up RAID-5 and create a zfs pool on top of it.How does SVM handle R5 write hole? IIRC SVM doesn't offer RAID-6.
It doesn't.
-- Robert Milkowski http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
