From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com, Eric Sandeen <sandeen@sandeen.net>,
aurfalien <aurfalien@gmail.com>
Subject: Re: specify agsize?
Date: Mon, 15 Jul 2013 11:07:22 +1000 [thread overview]
Message-ID: <20130715010721.GE5228@dastard> (raw)
In-Reply-To: <51E24E03.8010609@hardwarefreak.com>
On Sun, Jul 14, 2013 at 02:06:43AM -0500, Stan Hoeppner wrote:
> On 7/13/2013 11:20 PM, aurfalien wrote:
> ...
> >>> mkfs.xfs -f -l size=512m -d su=128k,sw=14 /dev/mapper/vg_doofus_data-lv_data
> ...
> >>> meta-data=/dev/mapper/vg_doofus_data-lv_data isize=256 agcount=32, agsize=209428640 blks
> >>> = sectsz=512 attr=2, projid32bit=0
> >>> data = bsize=4096 blocks=6701716480, imaxpct=5
> >>> = sunit=32 swidth=448 blks
> >>> naming =version 2 bsize=4096 ascii-ci=0
> >>> log =internal log bsize=4096 blocks=131072, version=2
> >>> = sectsz=512 sunit=32 blks, lazy-count=1
> >>> realtime =none extsz=4096 blocks=0, rtextents=0
> ...
> > Autodesk has this software called Flame which requires very very fast local storage using XFS.
>
> If "Flame" does any random writes then you probably shouldn't be using
> RAID6.
Oh, we are talking about flame/smoke/lustre rendering environments
here. Go back 5 years, a renderwall compositing effects via smoke
was one of the nastiest small random write workloads you could
throw at a filesystem. It was often used to benchmark file server
performance for renderwalls and still may be. Think of a workload
that reads lots of shared texture files across thousands of
machines, each crunching a single video frame to add an effect and
all doing small random writes to the video frame as it modifies a
small section of each line of the video frame....
Translation: tuning for AG size is a waste of time.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-15 1:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-14 0:11 specify agsize? aurfalien
2013-07-14 2:13 ` Eric Sandeen
2013-07-14 4:20 ` aurfalien
2013-07-14 7:06 ` Stan Hoeppner
2013-07-14 16:56 ` aurfalien
2013-07-15 1:07 ` Dave Chinner [this message]
2013-07-14 16:14 ` Eric Sandeen
2013-07-14 16:46 ` aurfalien
2013-07-14 17:14 ` aurfalien
2013-07-15 1:22 ` Dave Chinner
2013-07-14 22:08 ` Stan Hoeppner
2013-07-14 22:42 ` aurfalien
2013-07-14 23:43 ` Stan Hoeppner
-- strict thread matches above, loose matches on Subject: below --
2013-07-14 19:45 Richard Scobie
2013-07-14 22:18 ` aurfalien
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=20130715010721.GE5228@dastard \
--to=david@fromorbit.com \
--cc=aurfalien@gmail.com \
--cc=sandeen@sandeen.net \
--cc=stan@hardwarefreak.com \
--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