From mboxrd@z Thu Jan 1 00:00:00 1970 From: jim owens Subject: Re: thin provisioned LUN support & file system allocation policy Date: Fri, 07 Nov 2008 11:07:49 -0500 Message-ID: <491467D5.8000502@hp.com> References: <1225984628.4703.80.camel@localhost.localdomain> <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> <20081107153624.GG9543@mit.edu> <20081107154550.GH15439@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Wilcox , Theodore Tso , Ric Wheeler , Jens Axboe , Chris Mason , Dave Chinner , David Woodhouse , James Bottomley , linux-scsi@vger.kernel.org, Black_David@emc.com, "Martin K. Petersen" , Tom Coughlan , Eyal Shani To: linux-fsdevel@vger.kernel.org Return-path: In-Reply-To: <20081107154550.GH15439@parisc-linux.org> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org We have become confused and combined 2 independent issues... UNMAP thin storage array provisioning is not SSD TRIM. AFAIK the SSD trim will be handled just fine by sending the small size (merged when appropriate) trim command. The UNMAP is a big JBOD array problem and the solution(s) are different. As I said to one of Ric's early posts, my opinion is - expensive array vendors need to do this themselves because their whole thin provisioning thing is all about sharing on different host types with existing filesystems that use small blocks. - linux filesystems that can do large allocation blocks would be able to be tuned at mkfs to the array geometry if the vendors give us the data... and we should only optimize those filesystems and forget about trying to fix it in the block layer or fix it with some kind of defrag/scanner. jim