From: Stan Hoeppner <stan@hardwarefreak.com>
To: David Brown <david.brown@hesbynett.no>
Cc: GuoZhong Han <hanguozhong@meganovo.com>, linux-raid@vger.kernel.org
Subject: Re: make filesystem failed while the capacity of raid5 is big than 16TB
Date: Tue, 18 Sep 2012 16:38:39 -0500 [thread overview]
Message-ID: <5058E9DF.6090007@hardwarefreak.com> (raw)
In-Reply-To: <50584B75.1060606@hesbynett.no>
On 9/18/2012 5:22 AM, David Brown wrote:
> On 18/09/2012 11:35, GuoZhong Han wrote:
>> Hi Stan:
>> Thanks for your advice. In your last mail, you mentioned XFS
>> file system. According to your suggestion, I changed the file system
>> from raid5 (4*2T, chunksize: 128K, strip_catch_size:2048) to XFS. Then
>> I did a write performance test on XFS.
>> The test was as follows:
>> My program used 4 threads to do parallel writing to 30 files
>> with 1MB/s writing speed on each file. Each thread was bound on a
>> single core. The estimated total speed should be stable at 30MB/s. I
>> recorded the total writing speed every second in the test. Compared
>> with speed of ext4, when the array was going to be full, the
>> performance of XFS has indeed increased. The time to create the XFS
>> file system was much less than the cost of ext4. However, I found that
>> the total speed wasn’t steady. Although most of time the speed can
>> reach to 30M/s, it fell to only about 10MB/s in rare cases. Writing to
>> 30 files in parallel was supposed to be easy. Why did this happen?
>>
>>
>
> Two questions - what is the XFS built on? 4 x 2TB in a linear
> concatenation, or something else?
According to the above it's a 4 drive RAID5.
> Secondly, are all your files in the same directory, or in different
> directories? XFS scales by using multiple threads for different
> allocation groups,
This is partially correct if he's using the inode64 allocator. Do note
multiple XFS write threads can target the same AG and get parallel
performance. What you are referring to above is writing to multiple AGs
in parallel, where each AG resides on a different member device of a
concatenation.
Writing to say 16 AGs in parallel where all reside on the same disk
array will actually decrease performance compared to 16 writes to one AG
on that array. The reason is the latter causes far less head travel
between writes.
> and putting these groups in different places on the
> underlying disk or disks - but files in the same directory go in the
> same allocation group. So 30 files in 30 directories will give much
> more parallelism than 30 files in 1 directory.
Actually, no. The level of parallelism is the same--30 concurrent
writes. As noted above, the increase in performance comes from locating
each of the AGs on a different disk, or array. This decreases the
number of seeks requires per write, especially with parity arrays.
--
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-09-18 21:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 7:04 make filesystem failed while the capacity of raid5 is big than 16TB vincent
2012-09-12 7:32 ` Jack Wang
2012-09-12 7:37 ` Chris Dunlop
2012-09-12 7:58 ` David Brown
[not found] ` <CACY-59cLmV2SRY+FrvhHxseDD1+r-B-3bOKPGzJdGttW+9U2mw@mail.gmail.com>
2012-09-12 9:46 ` David Brown
2012-09-12 14:13 ` Stan Hoeppner
2012-09-13 7:06 ` David Brown
2012-09-13 3:21 ` GuoZhong Han
2012-09-13 3:34 ` Mathias Buren
2012-09-13 7:13 ` David Brown
2012-09-13 7:30 ` David Brown
2012-09-13 7:43 ` John Robinson
2012-09-13 9:15 ` David Brown
2012-09-13 13:25 ` Stan Hoeppner
2012-09-13 13:52 ` David Brown
2012-09-13 22:47 ` Stan Hoeppner
2012-09-18 9:35 ` GuoZhong Han
2012-09-18 10:22 ` David Brown
2012-09-18 21:38 ` Stan Hoeppner [this message]
2012-09-19 7:20 ` David Brown
2012-09-19 16:00 ` Stan Hoeppner
2012-09-18 21:20 ` Stan Hoeppner
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=5058E9DF.6090007@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=david.brown@hesbynett.no \
--cc=hanguozhong@meganovo.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 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).