Re: thin provisioned LUN support

[Ric Wheeler <rwheeler@redhat.com>]

Martin K. Petersen wrote:
>>>>>> "Ric" == Ric Wheeler <rwheeler@redhat.com> writes:
>>>>>>             
>
> Ric> After talking to some vendors, one issue that came up is that the
> Ric> arrays all have a different size that is used internally to track
> Ric> the SCSI equivalent of TRIM commands (POKE/unmap).
>
> I haven't had time to completely digest the latest (Nov. 4th) UNMAP
> proposal yet.  However, I don't recall seeing any notion of blocks
> bigger than the logical block length.  And the command clearly takes
> (a list of) <start LBA, number of blocks>.
>   

There is a proposal to expose this internal device size in a standard 
way, but it has not been finalized.

>
> Ric> What they would like is for us to coalesce these commands into
> Ric> aligned multiples of these chunks. 
>
> Ric> If not, the target device will most likely ignore the bits at the
> Ric> beginning and end (and all small requests).
>
> That really just sounds like a broken firmware implementation on their
> end.  If they can not UNMAP a single logical block then they are
> clearly not within the spirit of the proposed standard.  Their thin
> provisioning is going to suck and customers will hopefully
> complain/buy a competing product.
>
>   

I tend to agree with this point of view, but unfortunately, I think that 
all of the major arrays have this kind of limitation to one degree or 
another. I suspect that this will be a big deal with high end customers.

Just not sure that we have any way to handle this better than what is in 
already (best effort, maybe a post/defrag like user util that can be run 
offline to clean up?)

ric