Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754665Ab0KSOsV (ORCPT ); Fri, 19 Nov 2010 09:48:21 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:62240 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752255Ab0KSOsU (ORCPT ); Fri, 19 Nov 2010 09:48:20 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBACod5kxLd/sX/2dsb2JhbAAHgz3MP5EQgSKDNnMEhFqLEw X-IronPort-AV: E=Sophos;i="4.59,223,1288584000"; d="scan'208";a="82981650" Message-ID: <4CE68E2C.9070101@teksavvy.com> Date: Fri, 19 Nov 2010 09:48:12 -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: <1290100750.3041.72.camel@mulgrave.site> <1290102098.3041.77.camel@mulgrave.site> <4CE59E57.2090009@teksavvy.com> <4CE5C616.7070706@teksavvy.com> <20101119115516.GA1152@infradead.org> <4CE6831E.4020606@teksavvy.com> <20101119140639.GA25488@infradead.org> In-Reply-To: <20101119140639.GA25488@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: 1557 Lines: 33 On 10-11-19 09:06 AM, Christoph Hellwig wrote: > On Fri, Nov 19, 2010 at 09:01:02AM -0500, Mark Lord wrote: >> Ithink 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. > > That's certainly the easy way out. You'll need a good way to actually > transport the ranges as we can't simply sote them in bi_sector/bi_size > and adapt the whole block layer to deal with the two types of different > discards. Not saying it's impossible, but when I tried it before it > wasn't pretty. Yeah. I think for this to happen is has to be evolutionary, and the proposal above looks like a reasonable first crack at it. I'm not sure about the issues on "adapting the block layer" ? For FITRIM, the blocks being trimmed would be reserved at the fs level, before issuing the discard for them. So ordering through the block layer shouldn't matter much for it. Does that simplify things? I see FITRIM just allocating a page to hold the ranges (for the >1 case) and passing that page down through the layers to libata (or any other LLD that supports >1 ranges). ?? -- 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/