Thanks for all the answers more inline)

On 01/18/2013 02:42 AM, Richard Elling wrote:
> On Jan 17, 2013, at 7:04 AM, Bob Friesenhahn < 
> <>> wrote:
>> On Wed, 16 Jan 2013, Thomas Nau wrote:
>>> Dear all
>>> I've a question concerning possible performance tuning for both iSCSI access
>>> and replicating a ZVOL through zfs send/receive. We export ZVOLs with the
>>> default volblocksize of 8k to a bunch of Citrix Xen Servers through iSCSI.
>>> The pool is made of SAS2 disks (11 x 3-way mirrored) plus mirrored STEC RAM 
>>> ZIL
>>> SSDs and 128G of main memory
>>> The iSCSI access pattern (1 hour daytime average) looks like the following
>>> (Thanks to Richard Elling for the dtrace script)
>> If almost all of the I/Os are 4K, maybe your ZVOLs should use a volblocksize 
>> of 4K?  This seems like the most obvious improvement.
> 4k might be a little small. 8k will have less metadata overhead. In some cases
> we've seen good performance on these workloads up through 32k. Real pain
> is felt at 128k :-)

My only pain so far is the time a send/receive takes without really loading the
network at all. VM performance is nothing I worry about at all as it's pretty 
So key question for me is if going from 8k to 16k or even 32k would have some 
benefit for
that problem?

>> [ stuff removed ]
>>> For disaster recovery we plan to sync the pool as often as possible
>>> to a remote location. Running send/receive after a day or so seems to take
>>> a significant amount of time wading through all the blocks and we hardly
>>> see network average traffic going over 45MB/s (almost idle 1G link).
>>> So here's the question: would increasing/decreasing the volblocksize improve
>>> the send/receive operation and what influence might show for the iSCSI side?
>> Matching the volume block size to what the clients are actually using (due 
>> to their filesystem configuration) should improve
>> performance during normal operations and should reduce the number of blocks 
>> which need to be sent in the backup by reducing
>> write amplification due to "overlap" blocks..
> compression is a good win, too 

Thanks for that. I'll use your mentioned tools to drill down

>  -- richard


> --
> <>
> +1-760-896-4422

zfs-discuss mailing list

Reply via email to