|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Recent Linux file system benchmarks
|
- From: "K.S. Bhaskar" <bhaskar@bhaskars.com>
- To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
- Subject: Re: [PLUG] Recent Linux file system benchmarks
- Date: Mon, 18 Oct 2010 16:16:54 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=dD92EDfvLuLi9EDbzB0MSjh9CFp7qlpqWf9nkL4sozc=; b=b4m0Kjm4nTc5cbBWIYwbr5yOOooK3ZD/th5wgdq7maX1OzORtp6LBQlkMigHmsZZtR xtgLlqJpbp2ku/ZWwPy6Wy4fz0rwAyo5VLoEDCm84XMbhYXDLo6AgHwo2PMZv98jtsQe YSDkhTwIFIVSgrdqBKRDcPwqOsdyUB8PrE7RM=
- Reply-to: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
- Sender: plug-bounces@lists.phillylinux.org
Thanks, Lee. Comments below.
Regards
-- Bhaskar
On Mon, Oct 18, 2010 at 2:20 PM, Lee Marzke <lee@marzke.net> wrote:
> Bhasker,
>
> The btrfs results are disappointing if that's the performance will be
> expected in production.
[KSB] At the Linux End User Summit in Jersey City last week, I had an
opportunity to discuss the benchmark with some of the Red Hat
filesystem team. The default btrfs mount options are clearly not well
matched to the needs of a database. Perhaps turning off copy on write
will improve it. Another hypothesis is that GT.M triggers a known
current pathological behavior in btrfs - allocating a large sparse
file and then randomly writing blocks within it.
The good news is that btrfs is still under development (it doesn't
even have an fsck as yet) and the RH team has the benchmark. btrfs
certainly has some attractive features that I look forward to, such as
a near instant copy of an arbitrarily large file by copying the
metadata.
My original benchmark did not include xfs. One of the RH team
suggested it, and I was able to run a benchmark on it and include the
results. They also said several times that they did not expect one
file system to meet all application needs.
> ZFS/Fuse performance under Linux is also disappointing.
[KSB] I did not test zfs/fuse. Is this something that you tried
running the benchmark on? [If you did, any comments on making the
instructions easier to follow would be appreciated.]
> I'd be curious about performance of a NetApp filer ( which uses a
> propriatary WAFL
> filesystem, Âsimliar to ZFS ) however it has extensive caching that is
> supposed to vastly
> improve COW performance. Â ÂFrom what I understand caching writes in NVRAM
> is the secret
> to good performance with COW filesystems.
>
> Note that NetApps I've used ( FAS 2000 ) generally have 12 to 16 spindles
> per Aggregate
> SATA volume, so I'm not sure that's valid against your current benchmark.
> ÂBut, still having
> the advantages of using lots of snapshots without penalty, and still having
> a very fast SAN might be
> worth the cost of a NetApp. Â( Plus you get RAID-6 equiv protection , Âand
> with more
> spindles, and perhaps better performance than your RAID-0 striped SATA disks
> )
[KSB] If you have one, I'd be happy to help you set up the benchmark
and run it. It is my goal that anyone should be able to set up and
run the benchmark with just a few minutes effort. [The benchmark of
course can run for much longer.]
--
Windows does to computers what smoking does to humans
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|