[libvirt] [PATCH v2 2/8] storage_backend_iscsi_direct: Simplify vol zeroing

Michal Privoznik mprivozn at redhat.com
Fri Mar 15 15:12:17 UTC 2019


On 3/15/19 2:53 PM, Pavel Hrdina wrote:
> On Wed, Mar 06, 2019 at 03:59:12PM +0100, Michal Privoznik wrote:
>> So far we have two branches: either we zero BLOCK_PER_PACKET
>> (currently 128) block at one, or if we're close to the last block
>> then we zero out one block at the time. This is very suboptimal.
>> We know how many block are there left. Might as well just write
>> them all at once.
>>
>> Also, SCSI protocol has WRITESAME command which allows us to
>> write a single buffer multiple times. This means, that we have to
>> transfer the buffer far less frequently and have the destination
>> write it over and over again. Ideally, we would allocate a buffer
>> with size equivalent to block size of the LUN and then write it
>> as many times as there are blocks on the LUN. Sadly, this works
>> well in theory but in practise I've found out that it's possible
>> to write only 4096 blocks at once. Any higher value leads to a
>> failure. But still better than Twili^Wwhat we have now.
> 
> s/Twili^W//
> 
>> Since 4096 seems like an arbitrary number, I'm also implementing
>> a mechanism that exponentially decreases the number of blocks
>> we're trying to write at once. It starts at 4096 blocks and if
>> that's too much the number is halved, and so on.
> 
> According to documentation if you set 0 as the number of blocks it
> should write the same block starting at the LBA to the end of the
> device.  Would be nice to try it out and improve the algorithm to
> use only single transfer.

I've tried several values and found there are some differencies between 
docs and actual IMPL. What you suggest would be ideal of course, but the 
Linux Kernel I've tested doesn't allow me to specify anything else but 
[1, 4096]. Maybe it has something to do with the fact that LUN is 
virtualized and in fact a file on a filesystem. At any rate, we should 
be able to zero that too, shouldn't we?

Michal




More information about the libvir-list mailing list