Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760217Ab0KRULd (ORCPT ); Thu, 18 Nov 2010 15:11:33 -0500 Received: from mail-iw0-f174.google.com ([209.85.214.174]:41733 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755568Ab0KRULX convert rfc822-to-8bit (ORCPT ); Thu, 18 Nov 2010 15:11:23 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=d+fm8QgWPxCFQim7yWB+rKuORTzIwn7oZlOc9ZY70NMtysULkcLQM5InE3CBlydAGV J4Rld2STLzVD1SBxgy1evg2RfY9AzvuBvwXIgEG39KwngeWzCzmJAn4RL5S2I+E/cFYB tvjw5N2ibRzTh1rAVRX27XLHKkz+NxPWIZilI= MIME-Version: 1.0 In-Reply-To: <1290102098.3041.77.camel@mulgrave.site> References: <1290065809-3976-1-git-send-email-lczerner@redhat.com> <20101118130630.GJ6178@parisc-linux.org> <20101118134804.GN5618@dhcp231-156.rdu.redhat.com> <20101118141957.GK6178@parisc-linux.org> <20101118142918.GA18510@infradead.org> <1290100750.3041.72.camel@mulgrave.site> <1290102098.3041.77.camel@mulgrave.site> From: Greg Freemyer Date: Thu, 18 Nov 2010 12:04:31 -0800 Message-ID: Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation To: James Bottomley , Mark Lord Cc: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3114 Lines: 74 Adding Mark Lord in CC: On Thu, Nov 18, 2010 at 9:41 AM, James Bottomley wrote: > On Thu, 2010-11-18 at 12:22 -0500, Jeff Moyer wrote: >> James Bottomley writes: >> >> > Not stepping into the debate: I'm happy to see punch go to the mapping >> > data and FITRIM pick it up later. >> > >> > However, I think it's time to question whether we actually still want to >> > allow online discard at all. ?Most of the benchmarks show it to be a net >> >> Define online discard, please. > > Trims emitted inline at the FS operates (mount option -o discard) > >> > lose to almost everything (either SSD or Thinly Provisioned arrays), so >> > it's become an "enable this to degrade performance" option with no >> > upside. >> >> Some SSDs very much require TRIMming to perform well as they age. ?If >> you're suggesting that we move from doing discards in journal commits to >> a batched discard, like the one Lukas implemented, then I think that's >> fine. ?If we need to reintroduce the finer-grained discards due to some >> hardware changes in the future, we can always do that. > > Right, I'm suggesting we just rely on offline methods. ?Regardless of > what happens to FITRIM, we have wiper.sh now (although it does require > unmounted use for most of the less than modern fs). > > James I'm a fan of wiper.sh, but afaik it still cannot address a multi-spindle LVM setup, Nor a MDraid setup. etc. That's because it bypasses the block stack and talks directly to the devices. Thus it doesn't get the benefit of all the logical to physical sector remapping handled via the block stack. Mark, please correct me if I'm wrong. The LVM and MDraid setup are important to support, and only "mount -o discard" and Lucas's FITRIM support them. So afaik we have 3 options, each with an opportunity for improvement: 1) mount -o discard - needs kernel tuning / new hardware to be a performance win. 2) FITRIM doesn't leverage the fact the a TRIM command can handle multiple ranges per TRIM command payload. I haven't seen any FITRIM vs. wiper.sh benchmarks, so I don't know what impact that has in practice. Mark Lord thought that this lacking feature would cause FITRIM to take minutes or hours with some hardware. Especially early generation SSDs. 3) wiper.sh does leverage the multiple ranges per TRIM command, but it really needs a new block layer interface that would allow it to push discard commands into the kernel via the block layer, not just down at the physical drive layer. The interface should accept multiple ranges per invocation and trigger TRIM commands to the SSD that have have a multi-range discard payload. So it seems that for now keeping all 3 is best. My personal hope is that the block layer grows the ability to accept multirange discard requests and FITRIM is updated to leverage it. Greg -- 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/