linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org,
	Alan Piszcz <ap@solarrain.com>
Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations.
Date: Mon, 31 Dec 2007 10:22:53 -0500	[thread overview]
Message-ID: <4779094D.8050002@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0712301752550.29138@p34.internal.lan>

Justin Piszcz wrote:
> Dave's original e-mail:
>
>> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d 
>> agcount=4 <dev>
>> # mount -o logbsize=256k <dev> <mtpt>
>
>> And if you don't care about filsystem corruption on power loss:
>
>> # mount -o logbsize=256k,nobarrier <dev> <mtpt>
>
>> Those mkfs values (except for log size) will be hte defaults in the next
>> release of xfsprogs.
>
>> Cheers,
>
>> Dave.
>> -- 
>> Dave Chinner
>> Principal Engineer
>> SGI Australian Software Group
>
> ---------
>
> I used his mkfs.xfs options verbatim but I use my own mount options:
> noatime,nodiratime,logbufs=8,logbsize=26214
>
> Here are the results, the results of 3 bonnie++ averaged together for 
> each test:
> http://home.comcast.net/~jpiszcz/xfs1/result.html
>
> Thanks Dave, this looks nice--the more optimizations the better!
>
> -----------
>
> I also find it rather pecuilar that in some of my (other) benchmarks 
> my RAID 5 is just as fast as RAID 0 for extracting large files 
> (uncompressed) files:
>
> RAID 5 (1024k CHUNK)
> 26.95user 6.72system 0:37.89elapsed 88%CPU (0avgtext+0avgdata 
> 0maxresident)k0inputs+0outputs (6major+526minor)pagefaults 0swaps
>
> Compare with RAID 0 for the same operation:
>
> (as with RAID5, it appears 256k-1024k..2048k possibly) is the sweet spot.
>
> Why does mdadm still use 64k for the default chunk size?

Write performance with small files, I would think. There is some 
information in old posts, but I don't seem to find them as quickly as I 
would like.
>
> And another quick question, would there be any benefit to use (if it 
> were possible) a block size of > 4096 bytes with XFS (I assume only 
> IA64/similar arch can support it), e.g. x86_64 cannot because the 
> page_size is 4096.
>
> [ 8265.407137] XFS: only pagesize (4096) or less will currently work.


-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2007-12-31 15:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-30 23:04 New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations Justin Piszcz
2007-12-30 23:33 ` Raz
2007-12-30 23:44   ` Wolfgang Denk
2007-12-31  1:14 ` Richard Scobie
2007-12-31 15:05   ` Peter Grandi
2007-12-31 19:32     ` Richard Scobie
2007-12-31 15:22 ` Bill Davidsen [this message]
2008-01-04  5:35 ` Changliang Chen
2008-01-04  9:07   ` Justin Piszcz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4779094D.8050002@tmr.com \
    --to=davidsen@tmr.com \
    --cc=ap@solarrain.com \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).