Mag Gam on 22 Oct 2010 04:55:02 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Recent Linux file system benchmarks

  • From: Mag Gam <>
  • To: "Philadelphia Linux User's Group Discussion List" <>
  • Subject: Re: [PLUG] Recent Linux file system benchmarks
  • Date: Fri, 22 Oct 2010 07:54:57 -0400
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/o4KP1iLqhPFViul2ELP6PivuWTQcUbX3VI0SnMqYb4=; b=dNlO+XAwAvErmO1t/HTcqY4cDveg26v00Z3O23bxs8Ej3SazcYBYgCqyCmkSsdr8cj htxkWo1ykRU5CxUnPhwylFnyajKeictYoOQ+Qx++lk/ib4MxYII0a0pquKEIyG9BWbDp o9/g0nQWzrU+gf76M10GmHTqE1R3lyQmcNeTY=
  • Reply-to: Philadelphia Linux User's Group Discussion List <>
  • Sender:

Interesting to see how a database would perform with their native
filesystem/data management (ie ASM) against a Linux file system.

On Mon, Oct 18, 2010 at 4:16 PM, K.S. Bhaskar <> wrote:
> Thanks, Lee. ÂComments below.
> Regards
> -- Bhaskar
> On Mon, Oct 18, 2010 at 2:20 PM, Lee Marzke <> 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     --    Â
> Announcements -
> General Discussion Â-- Â
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --