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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
