Re: Thin provisioning & arrays

[Ric Wheeler <rwheeler@redhat.com>]

jim owens wrote:
> Ric Wheeler wrote:
>> Thing is being pitched to answer a very specific customer use case - 
>> shared storage (mid to high end almost exclusively) with several 
>> different users and applications....
>
> And by "different users" these customers almost always mean
> different operating systems.  They are combining storage into
> a central location for easier management.

When you have one specific LUN exported from an array, it is owned by 
one OS. You can definitely have different LUN's used by different OS's, 
but that seems to be irrelevant to our challenges here, right?
 
>
> So "exact unmapped tracking by the filesystem" is impossible
> and not part of the requirement.  Doesn't mean we can't make our
> filesystems better, but forget about a perfect ability to known
> just how much space we really have once we do an unmap.

My understanding is that most of this kind of information (how much real 
space is provisioned/utilized/etc) is handled out of band by a user 
space app.

>
> We can't tell how much of our unmapped space the device has
> given away to someone else and we cannot prevent the device
> from failing a write to an unmapped block if all the space
> is gone.  It is just an IO error, and possible fs-is-offline
> if that block we failed was metadata!

This is where things really fall apart - odd IO errors on a device that 
seems to us to have lots of space. If it becomes common in the field, I 
suspect that users will flee thin luns :-)  I also understand that other 
os'es are mutually unable to react.

>
> It is up to the customer to manage their storage so it never
> reaches the unable-to-write state.
>
> jim

Agreed - the high water marks should be set to allow the sys admin 
(storage admin?) to reallocate space....

ric