On 3/15/19 5:18 PM, Pavel Hrdina wrote: > 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. Ah, thank you for such in depth analysis. Yeah, we can't use it. So let me respin my original patch then. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
