> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Anatoly
> I've just made clean test for sequential data read. System has 45 mirror
> vdevs.

90 disks in the system...  I bet you have a lot of ram?

> 2. Read file normally:
> # time dd if=./big_file bs=128k of=/dev/null
> 161118683136 bytes (161 GB) copied, 103.455 seconds, 1.6 GB/s

I wonder how much of that is being read back from cache.  Would it be
impossible to reboot, or otherwise invalidate the cache, before reading the
file back?

With 90 disks, in theory, you should be able to read something like 90Gbit =
11GB / sec.  But of course various bus speed bottlenecks come into play, so
I don't think the 1.6GB/s is unrealistically high in any way.

> 3. Snapshot & send:
> # zfs snapshot volume/test@A
> # time zfs send volume/test@A > /dev/null
> real    7m20.635s
> user    0m0.004s
> sys     0m52.760s

This doesn't surprise me, based on gut feel, I don't think zfs send performs
optimally, in general.

I think your results are probably correct, and even if you revisit all this,
doing the reboots (or cache invalidation) and/or using a newly created pool,
as anyone here might suggest...  I think you'll still see the same results.
Somewhat unpredictably.

Even so, I always find zfs send performance still beats the pants off any
alternative... rsync and whatnot.

zfs-discuss mailing list

Reply via email to