[Top] [All Lists]

Re: Re: mkfs.xfs states log stripe unit is too large

To: "Dave Chinner" <david@xxxxxxxxxxxxx>, "Neil Brown" <neilb@xxxxxxx>
Subject: Re: Re: mkfs.xfs states log stripe unit is too large
From: kedacomkernel <kedacomkernel@xxxxxxxxx>
Date: Mon, 9 Jul 2012 20:02:28 +0800
Cc: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>, "Ingo J?rgensmann" <ij@xxxxxxxxxxxxxxxxxx>, xfs <xfs@xxxxxxxxxxx>, linux-raid <linux-raid@xxxxxxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type:content-transfer-encoding; bh=Nr22UfNkzo5e1iD5iot/85gWz0YN7i0OaCSnJ/quN9I=; b=NPZjZu5eEZoKkg591VkH0ft913R82qTtI18ngafaeokkHCneYhbwjJA6h6du8dPtUV jt52rknURJ8wNcCCO1H4cYCZZbUFiXAELsACjMBKQljzZskokQEpTADtaJ27D+zhCuoO gj9QRaIzWwjbI+1sJDaKPhSPgzycMAq37eFhLq24/tPX2f1v49lLTzz18RwNhNEoQu0J mlbpSXzD486BjdPprUbtK264SFRmc6suevdCELpOd+vQG4Kaw6hWuKFIRnkHX+/h80Fo iyxYyZ1LiNiHn5ZFVMzqNSNFidcSyL/VcYQJOtaqHftHkGxYARfLd/Bz98BSS8qX33V/ 6ZyA==
References: <D3F781FA-CEB0-4896-9441-772A9E533354@xxxxxxxxxxxxxxxxxx> <20120623234445.GZ19223@dastard> <4FE67970.2030008@xxxxxxxxxxx> <4FE710B7.5010704@xxxxxxxxxxxxxxxxx> <d71834a062ffd666ab53a4695eb643e9@xxxxxxxxxxxxxxxxxxxx> <20120626023059.GC19223@dastard> <20120626080217.GA30767@xxxxxxxxxxxxx> <20120702061827.GB16671@xxxxxxxxxxxxx> <20120702164113.109162be@xxxxxxxxxxxxxx>, <20120702080802.GQ19223@dastard>
On 2012-07-02 16:08 Dave Chinner <david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 
>> wrote:
>> > Ping to Neil / the raid list.
>> Thanks for the reminder.
>> > 
>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.
>Dave Chinner
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
<Prev in Thread] Current Thread [Next in Thread>