[PATCH md] Speed up raid10 resync, especially for 'far' layout

[PATCH md] Speed up raid10 resync, especially for 'far' layout

[Keld Jørn Simonsen]

Speed up raid10 resync, especially for 'far' layout

This patch speeds up resync for raid10, especially for the 'far' 
layout, where reading is done in 32 MiB increments and the moving of
heads is therefore much reduced compared to the previous 2 MiB size,
nd the 'far' property of striping read can be employed.

A speed up of more than 50 % has been reported.

Signed-off-by: Keld Simonsen <keld@dkuug.dk>

### Diffstat output:
 raid10.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -u linux-2.6.25.10/drivers/md/raid10.c linux-2.6.25.10-ks/drivers/md/raid10.c
--- linux-2.6.25.10/drivers/md/raid10.c	2008-07-03 05:46:47.000000000 +0200
+++ linux-2.6.25.10-ks/drivers/md/raid10.c	2008-07-12 18:28:59.438235317 +0200
@@ -80,7 +80,7 @@
 //#define RESYNC_BLOCK_SIZE PAGE_SIZE
 #define RESYNC_SECTORS (RESYNC_BLOCK_SIZE >> 9)
 #define RESYNC_PAGES ((RESYNC_BLOCK_SIZE + PAGE_SIZE-1) / PAGE_SIZE)
-#define RESYNC_WINDOW (2048*1024)
+#define RESYNC_WINDOW (2048*1024*16)
 
 /*
  * When performing a resync, we need to read and compare, so
@@ -686,7 +686,7 @@
  *    there is no normal IO happeing.  It must arrange to call
  *    lower_barrier when the particular background IO completes.
  */
-#define RESYNC_DEPTH 32
+#define RESYNC_DEPTH 32*16
 
 static void raise_barrier(conf_t *conf, int force)
 {

Re: [PATCH md] Speed up raid10 resync, especially for 'far' layout

[Jon Nelson]

On Tue, Aug 5, 2008 at 5:14 AM, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
> Speed up raid10 resync, especially for 'far' layout
>
> This patch speeds up resync for raid10, especially for the 'far'
> layout, where reading is done in 32 MiB increments and the moving of
> heads is therefore much reduced compared to the previous 2 MiB size,
> nd the 'far' property of striping read can be employed.
>
> A speed up of more than 50 % has been reported.

Actually, the time taken to 'check' the array was reduced by more than 50%.

-- 
Jon
--
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

Re: [PATCH md] Speed up raid10 resync, especially for 'far' layout

[Keld Jørn Simonsen]

On Tue, Aug 05, 2008 at 06:53:12AM -0500, Jon Nelson wrote:
> On Tue, Aug 5, 2008 at 5:14 AM, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
> > Speed up raid10 resync, especially for 'far' layout
> >
> > This patch speeds up resync for raid10, especially for the 'far'
> > layout, where reading is done in 32 MiB increments and the moving of
> > heads is therefore much reduced compared to the previous 2 MiB size,
> > nd the 'far' property of striping read can be employed.
> >
> > A speed up of more than 50 % has been reported.
> 
> Actually, the time taken to 'check' the array was reduced by more than 50%.

Which corresponds to a speed up of more than 100 %.

Did you  have any indications on whether there would still be room for
improvements? What was the speed on the individual disks compared to
their nominal speed?

best regards
keld
--
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

Re: [PATCH md] Speed up raid10 resync, especially for 'far' layout

[Jon Nelson]

On Tue, Aug 5, 2008 at 8:22 AM, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
> On Tue, Aug 05, 2008 at 06:53:12AM -0500, Jon Nelson wrote:
>> On Tue, Aug 5, 2008 at 5:14 AM, Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>> > Speed up raid10 resync, especially for 'far' layout
>> >
>> > This patch speeds up resync for raid10, especially for the 'far'
>> > layout, where reading is done in 32 MiB increments and the moving of
>> > heads is therefore much reduced compared to the previous 2 MiB size,
>> > nd the 'far' property of striping read can be employed.
>> >
>> > A speed up of more than 50 % has been reported.
>>
>> Actually, the time taken to 'check' the array was reduced by more than 50%.
>
> Which corresponds to a speed up of more than 100 %.
>
> Did you  have any indications on whether there would still be room for
> improvements? What was the speed on the individual disks compared to
> their nominal speed?

Generally, very good. At or above the posted speed limit.



-- 
Jon
--
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