Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

[Peter Lieven <pl@kamp.de>]

Am 17.07.2013 um 12:45 schrieb Paolo Bonzini <pbonzini@redhat.com>:

> Il 17/07/2013 12:21, Peter Lieven ha scritto:
>>>> BTW, Peter and Ronnie: we were assuming that UNMAP with LBPRZ=1 always
>>>> zeroes blocks, but is that true for unaligned operations?
>> Good question, I will pass it to ronnie. My guess is that the command will fail with
>> a check condition if it failed to unmap the data. From what Ronnie sent earlier
>> it should be guaranteed that the blocks are at least zero after the unmap command.
> 
> I'm not so sure about that, SBC says explicitly that a misaligned unmap
> request "may result in unmap operations on fewer LBAs than requested".
> 
> Perhaps it's better to do this:
> 
> - if LBPWS=1, use WRITE SAME(16).  For WRITE SAME it is explicit that
> "if the device server does not deallocate or anchor the LBA, then the
> device server shall perform the specified write operation".  Expose the
> value of LBPRZ in the "discard zeroes" field of BlockDriverInfo.
> 
> - if LBPWS=0, you can still support discard iff LBPU=1 and use UNMAP.
> But if LBPRZ=1 and LBPWS=0, you should not expose the "discard zeroes"
> field of BlockDriverInfo.
> 
>> As for the qemu-img patch this shouldn't matter. It uses always blocks of bdi->max_unmap
>> which should be a multiple of the alignment.
> 
> Also, the remainder itself (which SBC calls "UNMAP GRANULARITY
> ALIGNMENT") may not be 0.  I think the above trick (only exposing LBPRZ
> if you'll use WRITE SAME) will sidestep the problem.  It may also remove
> the need to fall back to has_zero_init=1.

You mean has_zero_init = 0?

What is if the max write same size and max unmap differ?

Peter

> 
> Paolo