Re: thin provisioned LUN support & file system allocation policy

[Theodore Tso <tytso@mit.edu>]

On Fri, Nov 07, 2008 at 10:26:04AM -0500, jim owens wrote:
> Ric Wheeler wrote:
>
>> The type of allocation that would help most is something that tries to  
>> keep the lower block ranges "hot" for allocation, second best policy  
>> would simply keep the allocated blocks in each block group hot and  
>> re-allocate them.
>
> This block reuse policy ignores the issue of wear leveling...
> as in most design things, trading one problem for another.
>

The discussion here has been around Intel-style SSD's, which
apparently have a log-structured filesystem in the device, such that
wear leveling is done automatically, and in fact it is *better* for
these devices if we reuse the same block since then the SSD
automatically knows that contents at the old location is logically
"gone".  (I don't believe, or at least don't see, why there would be
any benefit of reusing block ranges versus explicitly using a TRIM
command to tell the SSD that the old block was no longer being used;
it should have the same effect as far as the SSD is concerned.)

The one thing which I am somewhat concerned about is whether all SSD's
will be doing things the Intel way, or whether other SSD's might not
be willing to license some Intel patents (for example) and will end up
doing things some other way, where they aren't using a log-structured
filesystem under the covers and might be more succeptible to
wear-leveling concerns.

It would perhaps be unfortunate if we were to tune Linux filesystems
to be optimal for Intel-style SSD's, to the point where we can't
support other implementation strategies for SSD's where wear-leveling
might be more important.

OTOH, if Intel has lots of people engaging Linux, and helping to
provide code, benchmarking tools, etc., some bias towards SSD's as
designed and implemented by Intel is probably inevitable.  (And it's
an incentive for other SSD vendor's to do the same.  :-)

   	     	       	   	       	      - Ted