Am 17.07.2013 um 17:54 hat ronnie sahlberg geschrieben:
> On Wed, Jul 17, 2013 at 3:25 AM, Kevin Wolf <kw...@redhat.com> wrote:
> > Am 17.07.2013 um 11:58 hat Paolo Bonzini geschrieben:
> >> BTW, Peter and Ronnie: we were assuming that UNMAP with LBPRZ=1 always
> >> zeroes blocks, but is that true for unaligned operations?
> >
> > SBC-3 Rev. 35e, 5.16 READ CAPACITY (16) command:
> >
> > "A logical block provisioning read zeros (LBPRZ) bit set to one
> > indicates that, for read commands specifying an unmapped LBA (see
> > 4.7.4.5), the device server returns user data set to zero [...]"
> >
> > So it depends on the block provisioning state of the LBA, not on the
> > operations that were performed on it.
> >
> > 5.28 UNMAP command:
> >
> > If the ANCHOR bit in the CDB is set to zero, and the logical unit is
> > thin provisioned (see 4.7.3.3), then the logical block provisioning
> > state for each specified LBA:
> >
> > a) should become deallocated;
> > b) may become anchored; or
> > c) may remain unchanged.
> >
> > So with UNMAP, I think you don't have any guarantees that the LBA
> > becomes unmapped and therefore zeroed. It could just keep its current
> > data. No matter whether your request was aligned or not.
> >
>
> If you check the LogicalBlockLimits VPD page it has :
>
> ---
> [...]
> An unmap request with a starting LBA that is not optimal may result in
> unmap operations on fewer LBAs than
> requested.
> ---
>
> So if Peter checks OPTIMAL_UNMAP_GRANULARITY and
> UNMAP_GRANULARITY_ALIGNMENT and make sure that
> the starting LBA is (n * OUG) + UGA and that the number of blocks
> is a multiple of OUG then you should be fine.
Okay, playing language^Whardware spec lawyer...
You've got the logic backwards. The spec says "if misaligned then unmap
fewer LBAs". This is an implication, not an equivalence: It doesn't say
"if unmap fewer LBAs then misaligned". The sentence from the VPD page
just reinforces for a special case what I have quoted above (as take it
as a hint like "this would be the typical result").
The point is that the spec just says it "should" become deallocated, not
"must" or "shall", and there is no condition connected with it. "should"
is defined in the usual way (3.5.15):
3.5.13 should
a keyword indicating flexibility of choice with a strongly preferred
alternative; “should” is equivalent to the phrase “it is strongly
recommended”
So, it would be nice if UNMAP unmapped, but it doesn't have to.
> I think it is reasonable to assume that IF LBPRZ==1 and IF it is an
> "optimal unmap request" then the blocks will become unmapped and they
> will
> read back as 0.
It might be reasonable to expect in practice, but as I see it, it's not
demanded by the spec.
WRITE SAME is different, there you actually get the guarantee that the
desired data is read back. I strongly recommend using it over UNMAP
therefore if you don't want to discard, but write zeroes.
Kevin
