[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1011191907250.3238@dhcp-lab-213.englab.brq.redhat.com>
Date: Fri, 19 Nov 2010 19:10:16 +0100 (CET)
From: Lukas Czerner <lczerner@...hat.com>
To: Lukas Czerner <lczerner@...hat.com>
cc: Christoph Hellwig <hch@...radead.org>,
Greg Freemyer <greg.freemyer@...il.com>,
Mark Lord <kernel@...savvy.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
James Bottomley <James.Bottomley@...e.de>,
Jeff Moyer <jmoyer@...hat.com>,
Matthew Wilcox <matthew@....cx>,
Josef Bacik <josef@...hat.com>, tytso@....edu,
linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, sandeen@...hat.com
Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate
super_operation
On Fri, 19 Nov 2010, Lukas Czerner wrote:
> On Fri, 19 Nov 2010, Christoph Hellwig wrote:
>
> > On Fri, Nov 19, 2010 at 08:20:58AM -0800, Greg Freemyer wrote:
> > > The kernel team has been coding around some Utopian SSD TRIM
> > > implementation for at least 2 years with the basic assumption that
> > > SSDs can handle thousands of trims per second. Just mix em in with
> > > the rest of the i/o. No problem. Intel swore to us its the right
> > > thing to do.
> >
> > Thanks Greg, good that you told us what we've been doing. I would have
> > forgot myself if you didn't remember me.
> >
> > > I'm still waiting to see the first benchmark report from anywhere
> > > (SSD, Thin Provisioned SCSI) that the online approach used by mount -o
> > > discard is a win performance wise. Linux has a history of designing
> > > for reality, but for some reason when it comes to SSDs reality seems
> > > not to be a big concern.
> >
> > Both Lukas and I have done extensive benchmarks on various SSDs and
> > thinkly provisioned raids. Unfortunately most of the hardware is only
> > available under NDA so we can't publish it.
> >
> > For the XFS side which I've looked it I can summarize that we do have
> > arrays that do the online discard without measureable performance
> > penalty on various workloads, and we have devices (both SSDs and arrays)
> > where the overhead is incredibly huge. I can also say that doing the
> > walk of the freespace btrees similar to the offline discard, but every
> > 30 seconds or at a similarly high interval is a sure way to completely
> > kill performance.
> >
> > Or in short we haven't fund the holy grail yet.
> >
>
> Indeed we have not. But speaking of benchmarks I have just finished
> quick run (well, not so quick:)) of my discard-kit for btrfs filesystem
> and here are results. Note that tool used for this benchmark is
> postmark, hence it might not be the realest use-case, but it provides
> nice comparison between ext4 (below) and btrfs online discard
> implementation (FITRIM is NOT involved).
>
>
> (Sadly the table is too wide so you have to...well, you guys can manage
> it somehow, right?).
>
-snip-
In the sake of completeness here is an information how it was tested.
1. mkfs
2. mount -o (nodiscard|discard)
3. ./postmark
4. umount
5. repeat 1. - 4. ten times for each mnt option
-snip-
>
> (Buffering means that C library function like fopen, fread, fwrite are
> used instead of open, read, write. I have used the word buffering in the
> same way as it is used in the postmark test)
>
> So, you can see that Btrfs handles online discard quite better than ext4
> (cca 20% difference), but it is still pretty massive performance loss on
> not-so-good-but-I-have-seen-worse SSD. So, I would say that you guys
> (Josef?) should at least consider the possibility of using FITRIM as well.
>
> Thanks!
>
> -Lukas
>
--
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