qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert
Date: Wed, 17 Jul 2013 16:26:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 17/07/2013 16:21, Peter Lieven ha scritto:
> Am 17.07.2013 um 12:45 schrieb Paolo Bonzini <address@hidden>:
>> 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?

Yeah (copied the typo from you ;)).

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

You only need to consult one of the two, depending on whether you plan
to use WRITE SAME or UNMAP.  In other words, iscsi_open takes all the
decisions and stores the values that will be returned by BlockDriverInfo.

By the way, the semantics we gave to discard_zeroes, mean that
discard_zeroes must be 0 if the flags do not include BDRV_O_UNMAP.
Please ensure this is the case, and add an assertion about this in
bdrv_get_info.  Document everything that we decide about the semantics!

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]