Re: thin provisioned LUN support

[Ric Wheeler <rwheeler@redhat.com>]

Martin K. Petersen wrote:
>>>>>> "Ric" == Ric Wheeler <rwheeler@redhat.com> writes:
>>>>>>             
>
> Ric> Big arrays have an internal "track" size that is much larger than
> Ric> 512 bytes (Symm for example is 64k. Everything smaller than that
> Ric> is a read-modify-write. Effectively, they have few to no bits
> Ric> left to track this other bit of state at the smal level of
> Ric> granularity.
>
> My point still stands that this is an implementation problem in the
> array firmware.  It's not really our problem to solve.  Especially
> since drive vendors and mid-range storage vendors are getting it
> right.
>
> If EMC wants to provide thin provisioning on the Symmetrix they'll
> have to overcome the inherent limitations in their own internal
> architecture.
>
> What's next?  Requiring us to exclusively read and write in multiples
> of block sizes that are artifacts of internal array implementation
> details?
>
> For thin provisioning to really work on the Symm, then, we're
> effectively requiring the filesystem to use 64k filesystem blocks.
> Lame!
>
> I don't have a problem with honoring some bits akin to the block
> device characteristics VPD in trying to do a best-effort scheduling of
> the I/O.  But effectively disabling thin provisioning for blocks
> smaller than that is simply broken.
>   

Actually, the big arrays have larger "unmap" chunks than the 64k, so it 
is even more painful than that :-)

What is likely to happen is that "thin" will work for vendors with this 
kind of limitation in a very limited way and they will need to have some 
kind of user space tool to clean up the mess.

ric