From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: thin provisioned LUN support Date: Thu, 06 Nov 2008 11:00:50 -0500 Message-ID: <491314B2.9040902@redhat.com> References: <4913028B.6010405@redhat.com> <1225984628.4703.80.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: James Bottomley , Ric Wheeler , linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org, Black_David@emc.com, "Martin K. Petersen" , Tom Coughlan , Matthew Wilcox , Jens Axboe To: David Woodhouse Return-path: In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org David Woodhouse wrote: > On Thu, 6 Nov 2008, James Bottomley wrote: >> The way to do this properly would be to run a chequerboard of partials, >> but this would effectively have trim region tracking done in the block >> layer ... is this worth it? >> >> By the way, the latest (from 2 days ago) version of the Thin >> Provisioning proposal is here: >> >> http://www.t10.org/ftp/t10/document.08/08-149r4.pdf >> >> I skimmed it but don't see any update implying that trim might be >> ineffective if we align wrongly ... where is this? > > I think we should be content to declare such devices 'broken'. > > They have to keep track of individual sectors _anyway_, and dropping > information for small discard requests is just careless. > Big arrays have an internal "track" size that is much larger than 512 bytes (Symm for example is 64k. Everything smaller than that is a read-modify-write. Effectively, they have few to no bits left to track this other bit of state at the smal level of granularity. The thing that makes this even more twisted is that the erase/unmap chunk size is a multiple of the internal size (which would already be an issue :-)) Ric