[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <l2z87f94c371004191058pb88b1b89va325ceffb83ba604@mail.gmail.com>
Date: Mon, 19 Apr 2010 13:58:20 -0400
From: Greg Freemyer <greg.freemyer@...il.com>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
Jeff Moyer <jmoyer@...hat.com>,
Edward Shishkin <eshishki@...hat.com>,
Eric Sandeen <esandeen@...hat.com>,
Ric Wheeler <rwheeler@...hat.com>, Mark Lord <liml@....ca>
Subject: Re: Ext4: batched discard support
On Mon, Apr 19, 2010 at 12:30 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> Greg Freemyer wrote:
>> Adding Mark Lord in cc.
>>
>> He wrote a preliminary discard solution last summer. I'm not sure how
>> it has progressed.
>
> The difference here is that Mark's stuff wasn't as tightly integrated
> with the kernel, IIRC. What I saw was more at a user level - make a big
> file, map it, discard all the blocks, unlink the file.
>
> It was a good first step, but I think we can do a lot better by using
> fs-specific calls to be efficient & targeted about the discards.
>
> Christoph has a similar approach for XFS, FWIW.
>
> -Eric
I haven't looked closely at this patch, but I recall Mark consolidated
numerous discontinuous trim/discard/unmap ranges into a single command
to the SSD drive.
That was why he felt he was getting superior performance. ie. There
was an overhead per command to the drive that was eliminated if a
single more complex command with multiple ranges went to the SSD
drive.
But he's the one that did the work and the benchmarking, so I'll let
him take it from here, especially if I mis-understood what he was
doing.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists