public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: kedacomkernel <kedacomkernel@gmail.com>
To: Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-raid <linux-raid@vger.kernel.org>,
	Ingo J?rgensmann <ij@2012.bluespice.org>, xfs <xfs@oss.sgi.com>
Subject: Re: Re: mkfs.xfs states log stripe unit is too large
Date: Mon, 9 Jul 2012 20:02:28 +0800	[thread overview]
Message-ID: <201207092002243437160@gmail.com> (raw)
In-Reply-To: 20120702080802.GQ19223@dastard

On 2012-07-02 16:08 Dave Chinner <david@fromorbit.com> Wrote:
>On Mon, Jul 02, 2012 at 04:41:13PM +1000, NeilBrown wrote:
>> On Mon, 2 Jul 2012 02:18:27 -0400 Christoph Hellwig <hch@infradead.org> wrote:
>> 
>> > Ping to Neil / the raid list.
>> 
>> Thanks for the reminder.
>> 
>> > 
[snip]
>
>That's true, but the characterisitics of spinning disks have not
>changed in the past 20 years, nor has the typical file size
>distributions in filesystems, nor have the RAID5/6 algorithms. So
>it's not really clear to me why you;d woul deven consider changing
>the default the downsides of large chunk sizes on RAID5/6 volumes is
>well known. This may well explain the apparent increase in "XFS has
>hung but it's really just waiting for lots of really slow IO on MD"
>cases I've seen over the past couple of years.
>
At present, cat /sys/block/sdb/queue/max_sectors_kb:
is 512k. Maybe because this.

>The only time I'd ever consider stripe -widths- of more than 512k or
>1MB with RAID5/6 is if I knew my workload is almost exclusively
>using large files and sequential access with little metadata load,
>and there's relatively few workloads where that is the case.
>Typically those workloads measure throughput in GB/s and everyone
>uses hardware RAID for them because MD simply doesn't scale to this
>sort of usage.
>
>> If 512K is always suboptimal for XFS then that is unfortunate but I don't
>
>I think 512k chunk sizes are suboptimal for most users, regardless
>of the filesystem or workload....
>
>> think it is really possible to choose a default that everyone will be happy
>> with.  Maybe we just need more documentation and warning emitted by various
>> tools.  Maybe mkfs.xfs could augment the "stripe unit too large" message with
>> some text about choosing a smaller chunk size?
>
>We work to the mantra that XFS should always choose the defaults
>that give the best overall performance and aging characteristics so
>users don't need to be a storage expert to get the best the
>filesystem can offer. The XFS warning is there to indicate that the
>user might be doing something wrong. If that's being emitted with a
>default MD configuration, then that indicates that the MD defaults
>need to be revised....
>
>If you know what a stripe unit or chunk size is, then you know how
>to deal with the problem. But for the majority of people, that's way
>more knowledge than they are prepared to learn about or should be
>forced to learn about.
>
>Cheers,
>
>Dave.
>-- 
>Dave Chinner
>david@fromorbit.com
>--
>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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-07-09 12:01 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
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 [this message]
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=201207092002243437160@gmail.com \
    --to=kedacomkernel@gmail.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=ij@2012.bluespice.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --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