linux-ext4 - Re: ext4 write performance regression in 3.6-rc1 on RAID0/5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA9_cmc4t_P3p-72iZx4UALNe3fupVqBKvvsvCtMH6G3HZUdww@mail.gmail.com>
Date:	Wed, 22 Aug 2012 13:47:07 -0700
From:	Dan Williams <djbw@...com>
To:	NeilBrown <neilb@...e.de>
Cc:	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Li Shaohua <shli@...ionio.com>,
	"Theodore Ts'o" <tytso@....edu>, Marti Raudsepp <marti@...fo.org>,
	Kernel hackers <linux-kernel@...r.kernel.org>,
	ext4 hackers <linux-ext4@...r.kernel.org>, maze@...gle.com,
	"Shi, Alex" <alex.shi@...el.com>, linux-fsdevel@...r.kernel.org,
	linux RAID <linux-raid@...r.kernel.org>
Subject: Re: ext4 write performance regression in 3.6-rc1 on RAID0/5

On Tue, Aug 21, 2012 at 11:00 PM, NeilBrown <neilb@...e.de> wrote:
> On Wed, 22 Aug 2012 11:57:02 +0800 Yuanhan Liu <yuanhan.liu@...ux.intel.com>
> wrote:
>
>>
>> -#define NR_STRIPES           256
>> +#define NR_STRIPES           1024
>
> Changing one magic number into another magic number might help your case, but
> it not really a general solution.
>
> Possibly making sure that max_nr_stripes is at least some multiple of the
> chunk size might make sense, but I wouldn't want to see a very large multiple.
>
> I thing the problems with RAID5 are deeper than that.  Hopefully I'll figure
> out exactly what the best fix is soon - I'm trying to look into it.
>
> I don't think the size of the cache is a big part of the solution.  I think
> correct scheduling of IO is the real answer.

Not sure if this is what we are seeing here, but we still have the
unresolved fast parity effect whereby slower parity calculation gives
a larger time to coalesce writes.  I saw this effect when playing with
xor offload.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html