ZFS raid write performance?

[Xin Li]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/22/15 14:03, Quartz wrote:
>>> What's sequential write performance like these days for ZFS 
>>> raidzX? Someone suggested to me that I set up a single not-raid
>>> disk to act as a fast 'landing pad' for receiving files, then
>>> move them to the pool later in the background. Is that actually
>>> necessary? (Assume generic sata drives, 250mb-4gb sized files,
>>> and transfers are across a LAN using single unbonded GigE).
>> 
>> That sounds really weird recommendation IMHO.  Did "someone" 
>> explained with the reasoning/benefit of that "landing pad"?
> 
> Sort of. Something about the checksum calculations causing too much
> overhead. I think they were confused about sequential write vs 
> random

There are some overhead but it won't be the bottleneck if you are
using one GigE connection (not to mention that the default ZFS
checksum is not
SHA256 but a much faster algorithm), where network is the bottleneck.

> write, and possibly mdadm vs zfs. It was just something mentioned 
> in passing that I didn't want to start a debate about at the time, 
> since I wasn't 100% sure.
> 
>> a single hard drive won't do much beyond 100MB/s (maybe 120MB/s 
>> max) for sequential 128kB blocks, so that "landing pad" would 
>> probably not very helpful assuming you can saturate your GigE 
>> network
> 
> Wait, I'm confused. A single GigE has a theoretical max of like 
> 100mb/sec. That would imply the drive is probably about the same 
> speed?

No, what I'm trying to say is that since reading from the single drive
can't do much better than the network, it's likely that you wouldn't
be benefited by having it.

If the drive is much faster than the network and RAID-Z is much slower
than it, you could get some benefits because the unit you are using as
source of the replication can be re-purposed once data is on that
drive (which if I was to do the operation, I would probably never do
because that means less redundancy during migration).

Cheers,
- -- 
Xin LI <delphij at delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.5 (FreeBSD)

iQIcBAEBCgAGBQJViJFXAAoJEJW2GBstM+nsr3IP/AhXwYqg0MwXg+hbhl2kFhh2
w0lIbWwGe2KzttphJZDv+FORlnkUtynOS5YULiwavldup91DHyOZvru4HjuugBeR
BOW3Bkq4xOBVlzn9oW/BTMWbutevhmTBXG18iVxj2qwsy9NIuGL+1wyrYI5r5bl/
BaHBHYF6UXtr8Um77qZ8neKuv+ePGCCqYLei/paTc56XRnq5nlreulW8fxuHN4Pz
b3JPLzoaPdQOkcXtBe9V6ZlmdLvfBAmrCbD0gL0BDAeLsvkjRlQifwl+ZTSLeOtF
ja3bJ8tfCMFeGuRsL0RginiIn21if2rjZRuhWfUY0cDsPXgLVjseLLxc7F8NMwDt
rigkEuTTIfZy6UKD+70g05O2suN963Orqy1L6tfoAG0bEk9qH5ZoNl50F/fboRu/
68bAwTEMNo0x7h7XlCgB2GYS5qdDgsIeNbJLcDmXHmgTAyK/XM5/5pvSvXY2dYWN
/z/cYVHB8cVSwugcYZP/NQk8Eeldy2P+uZlUVqUSiWmk3m0x51VPyFJUtnnNIEf+
E4TupH/kyfZoiTgbsdCvfYqWm6YViNrjeZ8qa5qeGQnjDiNf1hCqyd/YbaCE0rHX
ACV4PyDkyW56uf+89uoKbn6QQMwb3FsL/6epODzLlSQYYDI+hvwN7PpKHQTnVFAS
gQutdcHlR3ZNiiLIO0ji
=bigs
-----END PGP SIGNATURE-----