Re: [PATCH 1/2] block: add support for discard limits

[James Bottomley <James.Bottomley@suse.de>]

On Mon, 2009-11-02 at 08:29 -0500, Martin K. Petersen wrote:
> >>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:
> 
> >> ACS-2 doesn't currently have a notion of unmap granularity and all
> >> array vendors I have talked to appear to happily process any unmap
> >> request we throw at them.  So I'm leaning towards keeping things
> >> simple and just sending things down verbatim...
> 
> Christoph> We have all the granularity and alignment information
> Christoph> avilable and keeping track of it is simple enough.
> 
> That's not the issue.
> 
> Nothing prevents you from submitting a misaligned read/write request to
> the array.  If you do, the array may be slower in servicing the request.
> But the entire request will still be serviced.
> 
> Similarly, nothing prevents you from submitting a misaligned unmap
> request.  If you do, the array will just ignore the portions that do not
> constitute entire allocation units.  Your code is taking what is a hint
> and turning it into a hard limit.  Note that it's called OPTIMAL UNMAP
> GRANULARITY, not REQUIRED UNMAP GRANULARITY.
> 
> Every vendor I have talked to have asked us to always unmap the *entire*
> LBA range we're interested in freeing.  No exceptions.
> 
> We don't throw away the beginning/end of a read/write request because
> it's not properly aligned either, do we?

Agree entirely for this with UNMAP, since the array will just silently
discard what it doesn't want.

Don't necessarily agree with this for WRITE_SAME.  From the
implementations I've read, it sounds like the array will discard all
sectors within the correct boundary and alignment but it will have to
write zeros to all sectors outside of the aligned region ... this sounds
like a performance hit unless we do some judicious aligning of the
discards.

James