From: Christoph Hellwig Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation Date: Fri, 19 Nov 2010 06:55:16 -0500 Message-ID: <20101119115516.GA1152@infradead.org> References: <20101118141957.GK6178@parisc-linux.org> <20101118142918.GA18510@infradead.org> <1290100750.3041.72.camel@mulgrave.site> <1290102098.3041.77.camel@mulgrave.site> <4CE59E57.2090009@teksavvy.com> <4CE5C616.7070706@teksavvy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mark Lord , "Martin K. Petersen" , James Bottomley , Jeff Moyer , Christoph Hellwig , Matthew Wilcox , Josef Bacik , Lukas Czerner , tytso@mit.edu, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, sandeen@redhat.com To: Greg Freemyer Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:40368 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444Ab0KSLzW (ORCPT ); Fri, 19 Nov 2010 06:55:22 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: On Thu, Nov 18, 2010 at 05:16:36PM -0800, Greg Freemyer wrote: > I agree with Mark. When you say "make coalescing work" it sounds like > major overkill. > > FITRIM should be able to lock a group of non-contiguous free ranges, > send them down to the block layer as a single pre-coalesced set, and > the block layer just needs to pass it on in a synchronous way. Then > when that group of ranges is discarded, FITRIM releases the locks. Given that you know the Linux I/O stack and hardware so well may I volunteer you to implement it? Including remapping the multiple ranges in device mapper, and dealing with the incompatible range formats for TRIM vs UNMAP. If your implementation is clean enough I'm pretty sure no one will object to merge it. > Every TRIM causes a cache flush anyway on the SSD, so the synchronous > aspect of the process should not be a problem. (Maybe SCSI with thin > provisioning would see a performance hit?) What's your evidence?