Re: thin provisioned LUN support

[Ric Wheeler <rwheeler@redhat.com>]

Chris Mason wrote:
> On Fri, 2008-11-07 at 10:18 -0600, James Bottomley wrote:
>   
>> On Fri, 2008-11-07 at 11:11 -0500, Chris Mason wrote:
>>     
>
> [ complex trim management code ]
>
>   
>>> It doesn't seem like a good idea to maintain a ton of code that gets
>>> exercised so rarely, especially wrt filesystem crashes.
>>>       
>> Heh, am I the only person here who deletes files on a regular basis
>> (principally to get my disk down from 99%)?
>>     
>
> Using it is easy, but the failure case is the storage forgets about a
> block the FS cares about, so actually testing the code means we have to
> test all the blocks allocated to the FS to make sure they have the
> correct values.  Given remapping and everything else we've talked about,
> any block in the FS could become corrupt due to a trim bug on block X.
>   

I don't think that trim bugs should be that common - we just have to be 
very careful never to send down a trim for any uncommitted block.

On write any unmapped (trimmed) sector becomes mapped again.
> So, trim bugs will look like a dozen other bugs, and they may not get
> reported for months after the actual bug was triggered (all things I
> know you already know ;)
>
> I think the bar for keeping it simple is much higher here than in other
> parts of the storage stack.
>
> -chris
>   

Simple is always good, but I still think that the coalescing (even basic 
coalescing) will be a critical performance feature.

ric