From: Eric Sandeen Subject: Re: [PATCH 2/2] Add batched discard support for ext4. Date: Sat, 24 Apr 2010 09:43:31 -0500 Message-ID: <4BD30393.4050800@redhat.com> References: <1271674527-2977-1-git-send-email-lczerner@redhat.com> <4BCE6243.5010209@teksavvy.com> <4BCE66C5.3060906@redhat.com> <4BCF4C53.3010608@redhat.com> <4BD2F69D.7070508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ric Wheeler , Lukas Czerner , Jeff Moyer , Mark Lord , linux-ext4@vger.kernel.org, Edward Shishkin , Eric Sandeen , Christoph Hellwig To: Greg Freemyer Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55775 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633Ab0DXOnn (ORCPT ); Sat, 24 Apr 2010 10:43:43 -0400 In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: Greg Freemyer wrote: > On Sat, Apr 24, 2010 at 9:48 AM, Ric Wheeler wrote: >> On 04/24/2010 09:24 AM, Greg Freemyer wrote: ... >>> I know I've been arguing against this patch for the single SSD case >>> and I still think that use case should be handled by userspace as >>> hdparm/wiper.sh currently does. In particular for those extreme >>> scenarios with JBOD SSDs, the user space solution wins because it >>> knows how to optimize the trim calls via vectorized ranges in the >>> payload. >>> >> I think that you have missed the broader point. This is not on by default, >> so you can mount without discard and use whatever user space utility you >> like at your discretion. >> >> ric > > Ric, > > I was trying to say the design should be driven by the large discard > range use case, not the potentially pathological small discard range > use case that would only benefit SSDs. > > Greg Bear in mind that this patch makes the discard range requests substantially -larger- than what mount -o discard does on ext4 today, in fact that was a main goal. If the kernel could assemble vectors of ranges and pass them down, I think it could be extended to use that as well. -Eric