xfs
[Top] [All Lists]

Re: mkfs.xfs error creating large agcount an raid

To: Marcus Pereira <marcus@xxxxxxxxxxx>
Subject: Re: mkfs.xfs error creating large agcount an raid
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Sun, 26 Jun 2011 18:29:33 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <4E07A41C.1000102@xxxxxxxxxxxxxxxxx>
References: <4E063BC6.9000801@xxxxxxxxxxx> <4E0694CC.8050003@xxxxxxxxxxxxxxxxx> <4E06C967.2060107@xxxxxxxxxxx> <4E07A41C.1000102@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
On 6/26/2011 4:26 PM, Stan Hoeppner wrote:
> On 6/26/2011 12:53 AM, Marcus Pereira wrote:

>> I got this idea at this post and was giving it a try:
>> http://www.techforce.com.br/news/linux_blog/lvm_raid_xfs_ext3_tuning_for_small_files_parallel_i_o_on_debian
> 
> Did you happen to notice that configuration has an IBM DS8300 SAN head
> with tons of BBWC and *512* fiber channel disks?  You have 8 disks.

The DS8300 has up to 256GB of read/write cache:
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp?topic=%2Fcom.ibm.storage.ssic.help.doc%2Ff2c_ds8300models922and9a2_1w2zq9.html

It's difficult to convey how critical the DS8300, its 8 processor cores,
and its gargantuan cache are in allowing the author to get away with
using so many small XFS allocation groups.  If his storage back end had
consisted of plain HBAs or relatively small cache RAID cards connected
to JBODs w/expanders, using that many small AGs would likely have caused
serious performance degradation instead of a performance increase.

Performance tuning is system specific.  You read a Ferrari tuning manual
and are attempting to apply that to tuning your Volkswagon.  That's
never going to work.

-- 
Stan

<Prev in Thread] Current Thread [Next in Thread>