qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1.8 4/6] block/iscsi: set bdi->cluster_size


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1.8 4/6] block/iscsi: set bdi->cluster_size
Date: Mon, 25 Nov 2013 15:51:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 25/11/2013 14:57, Peter Lieven ha scritto:
> +    /* Guess the internal cluster (page) size of the iscsi target by the 
> means
> +     * of opt_unmap_gran. Transfer the unmap granularity only if it has a
> +     * reasonable size for bdi->cluster_size */
> +    if (iscsilun->bl.opt_unmap_gran * iscsilun->block_size >= 64 * 1024 &&
> +        iscsilun->bl.opt_unmap_gran * iscsilun->block_size <= 16 * 1024 * 
> 1024) {
> +        bdi->cluster_size = iscsilun->bl.opt_unmap_gran * 
> iscsilun->block_size;
> +    }

I think you are mixing many different concepts:

* The optimal unmap granularity is good as a suggestion for the cluster
size of higher-level formats.

* The optimal transfer granularity (block limits page, bytes 6-7,
min_io_size in Linux) could be used to adjust the length of transfers in
"qemu-img convert".  I have not really thought much about *how* to do it.

* The optimal transfer (block limits page, bytes 12-15, opt_io_size in
Linux) should not be used in "qemu-img convert", I think, unless you can
actually report performance improvements.  This is because in "qemu-img
convert" we need to write the data anyway to the target.  We cannot
schedule other commands between two transfers.  So I don't think any
delays incurred by a very large write should matter.

The maximum transfer length (block limits page, bytes 8-11) should be
handled instead in the iSCSI driver, but I do not see the need to do
this unless we have reports of something not working.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]