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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
