• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Do RAID Z systems "stripe" within vdevs?

L

lordsegan

Gawd
Joined
Jun 16, 2004
Messages
624
Per this thread, I see a single vdev 4+ disk RAID Z setup getting 200+ MB/sec speeds.

I read on one forum that in a pool with a single vdev, speed is limited to the speed of the single slowest disk in the vdev. http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance

Does the above limitation only refer to random access and not sequential read/write? If I am streaming 1000 x 30 MB files to/from a single 4+2 disk vdev, will I see >GigEthernet speeds due to striping within the vdev?
 
Last edited:
A single Raid-Z vdev behaves like other Raid-O.
I/O performance is similar to a single disk because on every read or write all heads of all spindels must be positioned.

Regarding sequential read or writes, data to/from all disked is striped and written/read simultaniously to/from all disks.
So 1 Gb Network sequential transfer of a large file is not a problem for a single vdev. Its only a problem if you need to read or write a lot of small files or if you have concurrent Multi-User access.
 
Cool. There will be zero concurrent multi user access.

Would one thousand 30 megabyte files be considered "large" in the context of sequential transfer?
 
_Gea said:
I/O performance is similar to a single disk because on every read or write all heads of all spindels must be positioned.
Click to expand...
Someone here, said that for reading, all disks behave independently. But for writing, all disks must be positioned (to avoid the famous write-hole-error that ordinary hardware raid suffers from).

Can anyone confirm?
 
I believe that for raidz, all disks must be read to generate the correct data, so no parallelism, no. Also, the write hole is eliminated because of the COW nature of ZFS.
 
Correct - Copy-on-Write fixed the write-hole issue. Only once all disks have safely written their pieces of data does is the whole write itself considered complete and the uberblocks updated. If something failed/crashed during the write, the file is still at the 'version' it was before the write was started.
 
You must log in or register to reply here.
Back
Top