From: Stan Hoeppner <stan@hardwarefreak.com>
To: David Brown <david@westcontrol.com>
Cc: David Brown <david.brown@hesbynett.no>, linux-raid@vger.kernel.org
Subject: Re: RAID5 created by 8 disks works with xfs
Date: Mon, 02 Apr 2012 15:21:51 -0500 [thread overview]
Message-ID: <4F7A0A5F.8030107@hardwarefreak.com> (raw)
In-Reply-To: <4F794F6A.1010808@westcontrol.com>
On 4/2/2012 2:04 AM, David Brown wrote:
> On 02/04/2012 07:43, Stan Hoeppner wrote:
>> On 4/1/2012 5:33 AM, David Brown wrote:
>>
>>> For an application like this, it would probably make sense to put the
>>> xfs log (and the mdraid bitmap file, if you are using one) on a separate
>>> disk - perhaps a small SSD.
>>
>> XFS only journals metadata changes. Thus an external journal is not
>> needed here as there is no metadata in the workload.
>>
>
> Won't there still be metadata changes as each file is closed and a new
> one started,
Yes, creating one file requires one journal operation consisting of a
few dozen to a few hundred bytes of journal data. With delaylog this
will very likely be consolidated into a single IO to the journal, or a
handful of IOs. With the workload in question the number of journal IOs
is trivial.
> or as more space is allocated to the files being written (I
Allocation occurs once when the file is created.
> know xfs has delayed allocation and other tricks to minimise this, but
> it can't be eliminated entirely). Each time the metadata or log needs
> written, you'll get a big discontinuity in the writing as the disks
> heads need to jump around (especially for RAID5!).
The ratio of file IOs to metadata IOs in this workload is well north of
millions to one. Again, the metadata IOPS in this workload are trivial.
RAID level has no bearing on metadata IOPS here. Though it does for
the actual workload, as I already discussed in detail.
> It would make sense to have a separate disk (again, SSD is logical) for
> the OS and other files anyway, keeping the big array for the data.
> Putting the xfs log there too would surely be a small but helpful step?
No it doesn't make sense. See above. Additionally, an external journal
can only be used if the journal device is behind battery backed RAID
cache. Due to a design issue, XFS cannot perform barrier operations on
an external journal device, only to an internal journal. Without
barriers or BBWC you have the opportunity for constant filesystem
corruption. The OP doesn't have a BBWC RAID controller, nor any RAID
controller at all. So an external journal isn't an option here anyway.
--
Stan
next prev parent reply other threads:[~2012-04-02 20:21 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 1:22 RAID5 created by 8 disks works with xfs daobang wang
2012-03-31 7:59 ` Mathias Burén
2012-03-31 20:09 ` Stan Hoeppner
2012-04-01 1:16 ` daobang wang
2012-04-01 2:05 ` daobang wang
2012-04-01 5:13 ` Stan Hoeppner
2012-04-01 3:51 ` Stan Hoeppner
2012-04-01 5:12 ` daobang wang
2012-04-01 5:40 ` Stan Hoeppner
2012-04-01 5:59 ` daobang wang
2012-04-01 6:20 ` daobang wang
2012-04-01 7:08 ` Marcus Sorensen
2012-04-02 3:47 ` Stan Hoeppner
2012-04-05 0:48 ` daobang wang
[not found] ` <CACwgYDOtCoVF-p+KKqPYxHhA4vWF78Ueecx9hcVWLoyxFWzV9Q@mail.gmail.com>
2012-04-05 21:01 ` Stan Hoeppner
2012-04-05 21:01 ` Stan Hoeppner
2012-04-06 0:25 ` daobang wang
2012-04-06 0:25 ` daobang wang
2012-04-06 2:33 ` daobang wang
2012-04-06 2:33 ` daobang wang
2012-04-06 6:00 ` Jack Wang
2012-04-06 6:00 ` Jack Wang
2012-04-06 6:45 ` daobang wang
2012-04-06 6:45 ` daobang wang
2012-04-06 6:49 ` daobang wang
2012-04-06 6:49 ` daobang wang
2012-04-06 8:18 ` Stan Hoeppner
2012-04-06 8:18 ` Stan Hoeppner
2012-04-06 8:45 ` daobang wang
2012-04-06 8:45 ` daobang wang
2012-04-06 11:12 ` Stan Hoeppner
2012-04-06 11:12 ` Stan Hoeppner
2012-04-18 2:23 ` daobang wang
2012-04-18 2:23 ` daobang wang
2012-04-02 3:12 ` Stan Hoeppner
2012-04-01 10:33 ` David Brown
2012-04-01 12:28 ` John Robinson
2012-04-02 6:59 ` David Brown
[not found] ` <CA+res+QkLi7sxZrD-XOcbR47CeJ5gADf7P6pa1w1oMf8CKSB4g@mail.gmail.com>
2012-04-02 8:01 ` John Robinson
2012-04-02 10:01 ` Jack Wang
2012-04-02 10:28 ` John Robinson
2012-04-02 20:41 ` Stan Hoeppner
2012-04-02 5:43 ` Stan Hoeppner
2012-04-02 7:04 ` David Brown
2012-04-02 20:21 ` Stan Hoeppner [this message]
2012-04-01 4:52 ` Stan Hoeppner
2012-04-01 8:06 ` John Robinson
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=4F7A0A5F.8030107@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=david.brown@hesbynett.no \
--cc=david@westcontrol.com \
--cc=linux-raid@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.