Am 17.07.2013 um 12:45 schrieb Paolo Bonzini <pbonz...@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
