Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754429Ab0KSOBG (ORCPT ); Fri, 19 Nov 2010 09:01:06 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:28003 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752915Ab0KSOBF (ORCPT ); Fri, 19 Nov 2010 09:01:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAHMR5kxLd/sX/2dsb2JhbAAHgz3MLJELgSKDNnMEhFqLEw X-IronPort-AV: E=Sophos;i="4.59,223,1288584000"; d="scan'208";a="82977305" Message-ID: <4CE6831E.4020606@teksavvy.com> Date: Fri, 19 Nov 2010 09:01:02 -0500 From: Mark Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christoph Hellwig CC: Greg Freemyer , "Martin K. Petersen" , James Bottomley , Jeff Moyer , 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 Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation 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> <20101119115516.GA1152@infradead.org> In-Reply-To: <20101119115516.GA1152@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1839 Lines: 40 On 10-11-19 06:55 AM, Christoph Hellwig wrote: > 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? That is my intent already, thanks. Just needs time, perhaps this winter. I think a reasonable approach would be to modify the existing interfaces so that the LLD can report a "max discard ranges per command" back up the stack. This way, libata could report a max of say, 64 ranges per "discard" (trim), and DM/RAID could simply (for now) report a max of one range per discard. Way up at the FITRIM level, code could interrogate the "discard" limit for the device holding the fs, and construct the discard commands such that they respect that limit. For a filesystem on DM/RAID, we would (for now) end up with single-range discards, no change from the present. For the much more common case of end-user SATA SSDs, though, we would suddenly get multi-range trims working with probably very little effort. That's the plan. Feel free to beat me to it -- you've been working on the I/O stack nearly as long as I have (since 1992), and I expect you know it far better by now, too! ;) Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/