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

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