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. Pavel > > Michal
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
