From mboxrd@z Thu Jan  1 00:00:00 1970
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: thin provisioned LUN support & file system allocation policy
Date: Fri, 07 Nov 2008 09:36:35 -0600
Message-ID: <1226072195.8030.14.camel@localhost.localdomain>
References: <4913028B.6010405@redhat.com>
	 <1225984628.4703.80.camel@localhost.localdomain>
	 <Pine.LNX.4.64.0811061519350.3431@Nokia-N800-26>
	 <20081107120534.GO21867@kernel.dk> <49143142.4010809@redhat.com>
	 <20081107121934.GP21867@kernel.dk> <49145029.4040900@redhat.com>
	 <20081107144311.GE9543@mit.edu> <4914568A.7090307@redhat.com>
	 <49145E0C.4030705@hp.com>  <Pine.LNX.4.64.0811071528190.8115@Nokia-N800-26>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: jim owens <jowens@hp.com>, Ric Wheeler <rwheeler@redhat.com>,
	Theodore Tso <tytso@mit.edu>,
	Jens Axboe <jens.axboe@oracle.com>,
	Chris Mason <chris.mason@oracle.com>,
	Dave Chinner <david@fromorbit.com>, linux-scsi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Black_David@emc.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Tom Coughlan <coughlan@redhat.com>,
	Matthew Wilcox <matthew@wil.cx>
To: David Woodhouse <dwmw2@infradead.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from accolon.hansenpartnership.com ([76.243.235.52]:55403 "EHLO
	accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751490AbYKGPgn (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 7 Nov 2008 10:36:43 -0500
In-Reply-To: <Pine.LNX.4.64.0811071528190.8115@Nokia-N800-26>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Fri, 2008-11-07 at 15:31 +0000, David Woodhouse wrote:
> On Fri, 7 Nov 2008, 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.
> 
> For SSDs we're being told not to worry our pretty little heads about wear 
> levelling. That gets done for us, with varying degrees of competence, 
> within the black box. All we can do to improve that is pray... 
> and maybe sacrifice the occasional goat.

I think the rule is for SSDs that if they have a disk interface we
ignore wear levelling ... if the FTL is stupid, they're not going to be
reliable enough even for consumer use.   Trying to second guess the FTL
would be a layering violation (and a disaster in the making).

If we're being shown native flash with no intervening disk interface
then, yes, we need to do wear levelling (although I suspect this will
really only occur in the embedded space).

James