public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Helmut Tessarek <tessarek@evermeet.cx>,
	Eric Sandeen <sandeen@sandeen.net>,
	xfs@oss.sgi.com
Subject: Re: How to format RAID1 correctly
Date: Wed, 24 Sep 2014 14:06:59 -0500	[thread overview]
Message-ID: <54231653.7050600@hardwarefreak.com> (raw)
In-Reply-To: <5422E912.1000708@evermeet.cx>



On 09/24/2014 10:53 AM, Helmut Tessarek wrote:
> On 2014-09-24 0:09, Stan Hoeppner wrote:
>> If you create any striped arrays, especially parity arrays, with md make
>> sure to manually specify chunk size and match it to your workload.  The
>> current default is 512KB.  This is too large for a great many workloads,
>> specifically those that are metadata heavy or manipulate many small
>> files.  512KB wastes space and with parity arrays causes RMW, hammering
>> throughput and increasing latency.
> 
> Thanks again for the valueable information.
> 
> I used to work with databases on storage subsystems, so placing GBs of
> database containers for tableapaces on arrays with a larger stripe size
> was actually beneficial.
> For log files and other data I usually used different cache settings and
> strip sizes.
> 
> So how does this work with SW RAID?
> 
> Does the XFS chunk size equal the amount of data touched by a single r/w
> operation?

No.  The XFS stripe unit size (chunk size) must/should equal the
underlying RAID stripe unit size (chunk).  As Eric said, all this does
is help XFS align allocations to the underlying RAID geometry in an
attempt to get more full chunk/stripe writes on the disks.

Note we both said allocation.  The XFS sunit/swidth settings have no
affect with file appends or writing into preallocated files.

> I'm asking because data is usually written in page/extent sizes for
> databases. Even if I have a container with 50GB, I might only have to
> read/write a 4k page.

db operations are going to be append or modify-in-place.  Neither will
benefit from aligning XFS to the RAID geometry.  Appending the db logs
is also not allocation.  So in practical terms, you simply would not use
the "-d" striping options during mkfs.xfs.  Use the defaults.

Cheers,
Stan

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

      parent reply	other threads:[~2014-09-24 19:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24  0:46 How to format RAID1 correctly Helmut Tessarek
2014-09-24  2:05 ` Helmut Tessarek
2014-09-24  2:07 ` Eric Sandeen
2014-09-24  2:11   ` Helmut Tessarek
2014-09-24  2:21     ` Eric Sandeen
2014-09-24  2:30       ` Helmut Tessarek
2014-09-24  3:05     ` stan hoeppner
2014-09-24  3:15       ` Helmut Tessarek
2014-09-24  4:09         ` Stan Hoeppner
2014-09-24 15:53           ` Helmut Tessarek
2014-09-24 16:18             ` Eric Sandeen
2014-09-24 19:06             ` Stan Hoeppner [this message]

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=54231653.7050600@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=sandeen@sandeen.net \
    --cc=tessarek@evermeet.cx \
    --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