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

On Fri, Mar 15, 2019 at 04:12:17PM +0100, Michal Privoznik wrote: > 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? So I was able to find the limit in linux source code and the limit is 4096 for file-based block stores. It looks like that the WRITESAME command is not supported by ramdisk backstore so we probably cannot use it to wipe the iscsi volumes.