public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: david@lang.hm
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
	Justin Piszcz <jpiszcz@lucidpixels.com>,
	Alex Elder <aelder@sgi.com>, Mark Lord <kernel@teksavvy.com>
Subject: Re: xfs: very slow after mount, very slow at umount
Date: Thu, 27 Jan 2011 17:53:18 -0600	[thread overview]
Message-ID: <4D42056E.2050505@hardwarefreak.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1101271209370.17579@asgard.lang.hm>

david@lang.hm put forth on 1/27/2011 2:11 PM:

> how do I understand how to setup things on multi-disk systems? the documentation
> I've found online is not that helpful, and in some ways contradictory.

Visit http://xfs.org  There you will find:

Users guide:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/index.html

File system structure:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html

Training labs:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_Labs/tmp/en-US/html/index.html

> If there really are good rules for how to do this, it would be very helpful if
> you could just give mkfs.xfs the information about your system (this partition
> is on a 16 drive raid6 array) and have it do the right thing.

If your disk array is built upon Linux mdraid, recent versions of mkfs.xfs will
read the parameters and automatically make the filesystem accordingly, properly.

mxfs.fxs will not do this for PCIe/x hardware RAID arrays or external FC/iSCSI
based SAN arrays as there is no standard place to acquire the RAID configuration
information for such systems.  For these you will need to configure mkfs.xfs
manually.

At minimum you will want to specify stripe width (sw) which needs to match the
hardware stripe width.  For RAID0 sw=[#of_disks].  For RAID 10, sw=[#disks/2].
For RAID5 sw=[#disks-1].  For RAID6 sw=[#disks-2].

You'll want at minimum agcount=16 for striped hardware arrays.  Depending on the
number and spindle speed of the disks, the total size of the array, the
characteristics of the RAID controller (big or small cache), you may want to
increase agcount.  Experimentation may be required to find the optimum
parameters for a given hardware RAID array.  Typically all other parameters may
be left at defaults.

Picking the perfect mkfs.xfs parameters for a hardware RAID array can be
somewhat of a black art, mainly because no two vendor arrays act or perform
identically.

Systems of a caliber requiring XFS should be thoroughly tested before going into
production.  Testing _with your workload_ of multiple parameters should be
performed to identify those yielding best performance.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-01-27 23:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4D40C8D1.8090202@teksavvy.com>
2011-01-27  3:30 ` xfs: very slow after mount, very slow at umount Dave Chinner
2011-01-27  3:49   ` Mark Lord
2011-01-27  5:17     ` Stan Hoeppner
2011-01-27 15:12     ` Mark Lord
2011-01-27 15:40       ` Justin Piszcz
2011-01-27 16:03         ` Mark Lord
2011-01-27 19:40           ` Stan Hoeppner
2011-01-27 20:11             ` david
2011-01-27 23:53               ` Stan Hoeppner [this message]
2011-01-28  2:09                 ` david
2011-01-28 13:56                   ` Dave Chinner
2011-01-28 19:26                     ` david
2011-01-29  5:40                       ` Dave Chinner
2011-01-29  6:08                         ` david
2011-01-29  7:35                           ` Dave Chinner
2011-01-31 19:17                             ` Christoph Hellwig
2011-01-27 21:56             ` Mark Lord
2011-01-28  0:17               ` Dave Chinner
2011-01-28  1:22                 ` Mark Lord
2011-01-28  1:36                   ` Mark Lord
2011-01-28  4:14                   ` David Rees
2011-01-28 14:22                     ` Mark Lord
2011-01-28  7:31                   ` Dave Chinner
2011-01-28 14:33                     ` Mark Lord
2011-01-28 23:58                       ` Dave Chinner
2011-01-28 19:18             ` Martin Steigerwald
2011-01-27 20:24           ` John Stoffel
2011-01-27 23:41       ` Dave Chinner
2011-01-28  0:59         ` Mark Lord
2011-01-27 23:39     ` Dave Chinner
     [not found] ` <4D40CDCF.4010301@teksavvy.com>
2011-01-27  3:43   ` Dave Chinner
2011-01-27  3:53     ` Mark Lord
2011-01-27  4:54       ` Mark Lord
2011-01-27 23:34       ` Dave Chinner

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=4D42056E.2050505@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=aelder@sgi.com \
    --cc=david@lang.hm \
    --cc=hch@infradead.org \
    --cc=jpiszcz@lucidpixels.com \
    --cc=kernel@teksavvy.com \
    --cc=linux-kernel@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