public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: =?ISO-8859-1?Q?Ingo_J=FCrgensma?=@oss.sgi.com,
	nn <ij@2012.bluespice.org>,
	xfs@oss.sgi.com
Subject: Re: mkfs.xfs states log stripe unit is too large
Date: Sun, 24 Jun 2012 08:05:59 -0500	[thread overview]
Message-ID: <4FE710B7.5010704@hardwarefreak.com> (raw)
In-Reply-To: <4FE67970.2030008@sandeen.net>

On 6/23/2012 9:20 PM, Eric Sandeen wrote:
> On 6/23/12 6:44 PM, Dave Chinner wrote:
>> On Sat, Jun 23, 2012 at 02:50:49PM +0200, Ingo Jürgensmann wrote:
>>> muaddib:~# cat /proc/mdstat 
>>> Personalities : [raid1] [raid6] [raid5] [raid4] 
>>> md7 : active raid5 sdf4[3] sdd4[1] sde4[0]
>>>       7811261440 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
                                               ^^^^^^^^^^

The the log stripe unit mismatch error is a direct result of Ingo
manually choosing a rather large chunk size for his two stripe spindle
md array, yielding a 1MB stripe, and using an internal log with it.
Maybe there is a good reason for this, but I'm going to challenge it.

The default md chunk size IIRC is 64KB, 8x smaller than Ingo's chunk.
With the default it would require 16 stripe spindles to reach a 1MB
stripe.  Ingo has TWO stripe spindles.

In the default case with a 1MB stripe and 16 spindles, each aligned
aggregated stripe write out will be 256 XFS blocks, or 16 blocks to each
spindle, 128 sectors (512 byte).  In Ingo's case, it will be 128 XFS
blocks, 1024 sectors.

Does backup PC perform better writing 2048 sectors per stripe write,
1024 per spindle, with two spindles, than 256 sectors per stripe write,
128 per spindle, using two spindles?

>> .....
>>
>>> The RAID devices /dev/md0 to /dev/md4 are on my old 3x 1 TB
>>> Seagate disks. Anyway, to finally come to the problem, when I try
>>> to create a filesystem on the new RAID5 I get the following:  
>>>
>>> muaddib:~# mkfs.xfs /dev/lv/usr
>>> log stripe unit (524288 bytes) is too large (maximum is 256KiB)
>>> log stripe unit adjusted to 32KiB
> 
> ...
> 
>>
>>> So, the question is: 
>>> - is this a bug somewhere in XFS, LVM or Linux's software RAID
>>> implementation?
>>
>> Not a bug at all.
> 
> Dave, I'd suggest that we should remove the warning though, if XFS picks
> the wrong defaults and then overrides itself.
> 
> Rule of Silence: When a program has nothing surprising to say, it should say nothing.

I think this goes to the heart of the matter.  Ingo chose an arbitrarily
large chunk size apparently without understanding the ramifications.
mkfs.xfs was written to read md parameters I believe with the assumption
the parameters were md defaults.  It obviously wasn't written to
gracefully deal with a manually configured arbitrarily large md chunks size.

Maybe a better solution than silence here would be education.  Flag the
mismatch as we do now, and provide a URL to a new FAQ entry that
explains why this occurs, and possible solutions to the problem, the
first recommendation being to choose a sane chunk size.

Question:  does this occur with hardware RAID when entering all the same
parameters manually on the command line?  Or is this error limited to
the md interrogation path?

-- 
Stan

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

  reply	other threads:[~2012-06-24 13:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-23 12:50 mkfs.xfs states log stripe unit is too large Ingo Jürgensmann
2012-06-23 23:44 ` Dave Chinner
2012-06-24  2:20   ` Eric Sandeen
2012-06-24 13:05     ` Stan Hoeppner [this message]
2012-06-24 13:17       ` Ingo Jürgensmann
2012-06-24 19:28         ` Stan Hoeppner
2012-06-24 19:51           ` Ingo Jürgensmann
2012-06-24 22:15             ` Stan Hoeppner
2012-06-25  5:25               ` Ingo Jürgensmann
     [not found]                 ` <4FE8CEED.7070505@hardwarefreak.com>
2012-06-25 21:18                   ` Ingo Jürgensmann
2012-06-24 15:03       ` Ingo Jürgensmann
2012-06-26  2:30         ` Dave Chinner
2012-06-26  8:02           ` Christoph Hellwig
     [not found]             ` <20120702061827.GB16671@infradead.org>
2012-07-02  6:41               ` NeilBrown
2012-07-02  8:08                 ` Dave Chinner
2012-07-09 12:02                   ` kedacomkernel
2012-06-26 19:34           ` Ingo Jürgensmann
2012-06-27  2:06           ` Eric Sandeen
2012-06-25 10:33   ` Ingo Jürgensmann

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=4FE710B7.5010704@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc==?ISO-8859-1?Q?Ingo_J=FCrgensma?=@oss.sgi.com \
    --cc=ij@2012.bluespice.org \
    --cc=sandeen@sandeen.net \
    --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