Re: thin provisioned LUN support

Ric Wheeler
2008-11-06T15:42:52Z

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