* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree [not found] <12718801381479@kroah.org> @ 2010-04-22 2:08 ` Stefan Lippers-Hollmann 2010-04-22 2:40 ` Neil Brown 0 siblings, 1 reply; 6+ messages in thread From: Stefan Lippers-Hollmann @ 2010-04-22 2:08 UTC (permalink / raw) To: gregkh; +Cc: linux-kernel, neilb, king.br, stable Hi On Thursday 22 April 2010, gregkh@suse.de wrote: > This is a note to let you know that we have just queued up the patch titled > > Subject: md/raid5: allow for more than 2^31 chunks. > > to the 2.6.33-stable tree. Its filename is > > md-raid5-allow-for-more-than-2-31-chunks.patch > > A git repo of this tree can be found at > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > From: NeilBrown <neilb@suse.de> > Date: Tue, 20 Apr 2010 14:13:34 +1000 > Subject: md/raid5: allow for more than 2^31 chunks. > > From: NeilBrown <neilb@suse.de> > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > With many large drives and small chunk sizes it is possible > to create a RAID5 with more than 2^31 chunks. Make sure this > works. > > Reported-by: Brett King <king.br@gmail.com> > Signed-off-by: NeilBrown <neilb@suse.de> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> This patch, as part of the current 2.6.33 stable queue, breaks compiling on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): [...] BUILD arch/x86/boot/bzImage Root device is (254, 6) Setup is 12700 bytes (padded to 12800 bytes). System is 2415 kB CRC db6fa5fa Kernel: arch/x86/boot/bzImage is ready (#1) ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! reverting just this patch fixes the problem for me. Current Debian/ unstable: ii binutils 2.20.1-7 The GNU assembler, linker and binary utilities ii gcc-4.4 4.4.3-9 The GNU C compiler ii make 3.81-8 An utility for Directing compilation. Regards Stefan Lippers-Hollmann -- > --- > drivers/md/raid5.c | 19 +++++++------------ > 1 file changed, 7 insertions(+), 12 deletions(-) > > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -1649,8 +1649,8 @@ static sector_t raid5_compute_sector(rai > int previous, int *dd_idx, > struct stripe_head *sh) > { > - long stripe; > - unsigned long chunk_number; > + sector_t stripe; > + sector_t chunk_number; > unsigned int chunk_offset; > int pd_idx, qd_idx; > int ddf_layout = 0; > @@ -1670,17 +1670,12 @@ static sector_t raid5_compute_sector(rai > */ > chunk_offset = sector_div(r_sector, sectors_per_chunk); > chunk_number = r_sector; > - BUG_ON(r_sector != chunk_number); > > /* > * Compute the stripe number > */ > - stripe = chunk_number / data_disks; > - > - /* > - * Compute the data disk and parity disk indexes inside the stripe > - */ > - *dd_idx = chunk_number % data_disks; > + stripe = chunk_number; > + *dd_idx = sector_div(stripe, data_disks); > > /* > * Select the parity disk based on the user selected algorithm. > @@ -1869,14 +1864,14 @@ static sector_t compute_blocknr(struct s > : conf->algorithm; > sector_t stripe; > int chunk_offset; > - int chunk_number, dummy1, dd_idx = i; > + sector_t chunk_number; > + int dummy1, dd_idx = i; > sector_t r_sector; > struct stripe_head sh2; > > > chunk_offset = sector_div(new_sector, sectors_per_chunk); > stripe = new_sector; > - BUG_ON(new_sector != stripe); > > if (i == sh->pd_idx) > return 0; > @@ -1969,7 +1964,7 @@ static sector_t compute_blocknr(struct s > } > > chunk_number = stripe * data_disks + i; > - r_sector = (sector_t)chunk_number * sectors_per_chunk + chunk_offset; > + r_sector = chunk_number * sectors_per_chunk + chunk_offset; > > check = raid5_compute_sector(conf, r_sector, > previous, &dummy1, &sh2); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree 2010-04-22 2:08 ` patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree Stefan Lippers-Hollmann @ 2010-04-22 2:40 ` Neil Brown 2010-04-22 11:36 ` Stefan Lippers-Hollmann 0 siblings, 1 reply; 6+ messages in thread From: Neil Brown @ 2010-04-22 2:40 UTC (permalink / raw) To: Stefan Lippers-Hollmann; +Cc: gregkh, linux-kernel, king.br, stable On Thu, 22 Apr 2010 04:08:30 +0200 "Stefan Lippers-Hollmann" <s.L-H@gmx.de> wrote: > Hi > > On Thursday 22 April 2010, gregkh@suse.de wrote: > > This is a note to let you know that we have just queued up the patch titled > > > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > to the 2.6.33-stable tree. Its filename is > > > > md-raid5-allow-for-more-than-2-31-chunks.patch > > > > A git repo of this tree can be found at > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > > From: NeilBrown <neilb@suse.de> > > Date: Tue, 20 Apr 2010 14:13:34 +1000 > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > From: NeilBrown <neilb@suse.de> > > > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > > > With many large drives and small chunk sizes it is possible > > to create a RAID5 with more than 2^31 chunks. Make sure this > > works. > > > > Reported-by: Brett King <king.br@gmail.com> > > Signed-off-by: NeilBrown <neilb@suse.de> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > This patch, as part of the current 2.6.33 stable queue, breaks compiling > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): > > [...] > BUILD arch/x86/boot/bzImage > Root device is (254, 6) > Setup is 12700 bytes (padded to 12800 bytes). > System is 2415 kB > CRC db6fa5fa > Kernel: arch/x86/boot/bzImage is ready (#1) > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! > > reverting just this patch fixes the problem for me. Thanks for testing and reporting. If you could verify that this additional patch fixes the compile error I would really appreciate it. Thanks, NeilBrown diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 20e4840..58ea0ec 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -1650,7 +1650,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, int previous, int *dd_idx, struct stripe_head *sh) { - sector_t stripe; + sector_t stripe, stripe2; sector_t chunk_number; unsigned int chunk_offset; int pd_idx, qd_idx; @@ -1677,7 +1677,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, */ stripe = chunk_number; *dd_idx = sector_div(stripe, data_disks); - + stripe2 = stripe; /* * Select the parity disk based on the user selected algorithm. */ @@ -1689,21 +1689,21 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, case 5: switch (algorithm) { case ALGORITHM_LEFT_ASYMMETRIC: - pd_idx = data_disks - stripe % raid_disks; + pd_idx = data_disks - sector_div(stripe2, raid_disks); if (*dd_idx >= pd_idx) (*dd_idx)++; break; case ALGORITHM_RIGHT_ASYMMETRIC: - pd_idx = stripe % raid_disks; + pd_idx = sector_div(stripe2, raid_disks); if (*dd_idx >= pd_idx) (*dd_idx)++; break; case ALGORITHM_LEFT_SYMMETRIC: - pd_idx = data_disks - stripe % raid_disks; + pd_idx = data_disks - sector_div(stripe2, raid_disks); *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; break; case ALGORITHM_RIGHT_SYMMETRIC: - pd_idx = stripe % raid_disks; + pd_idx = sector_div(stripe2, raid_disks); *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; break; case ALGORITHM_PARITY_0: @@ -1723,7 +1723,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, switch (algorithm) { case ALGORITHM_LEFT_ASYMMETRIC: - pd_idx = raid_disks - 1 - (stripe % raid_disks); + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); qd_idx = pd_idx + 1; if (pd_idx == raid_disks-1) { (*dd_idx)++; /* Q D D D P */ @@ -1732,7 +1732,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, (*dd_idx) += 2; /* D D P Q D */ break; case ALGORITHM_RIGHT_ASYMMETRIC: - pd_idx = stripe % raid_disks; + pd_idx = sector_div(stripe2, raid_disks); qd_idx = pd_idx + 1; if (pd_idx == raid_disks-1) { (*dd_idx)++; /* Q D D D P */ @@ -1741,12 +1741,12 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, (*dd_idx) += 2; /* D D P Q D */ break; case ALGORITHM_LEFT_SYMMETRIC: - pd_idx = raid_disks - 1 - (stripe % raid_disks); + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); qd_idx = (pd_idx + 1) % raid_disks; *dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks; break; case ALGORITHM_RIGHT_SYMMETRIC: - pd_idx = stripe % raid_disks; + pd_idx = sector_div(stripe2, raid_disks); qd_idx = (pd_idx + 1) % raid_disks; *dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks; break; @@ -1765,7 +1765,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, /* Exactly the same as RIGHT_ASYMMETRIC, but or * of blocks for computing Q is different. */ - pd_idx = stripe % raid_disks; + pd_idx = sector_div(stripe2, raid_disks); qd_idx = pd_idx + 1; if (pd_idx == raid_disks-1) { (*dd_idx)++; /* Q D D D P */ @@ -1780,7 +1780,8 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, * D D D P Q rather than * Q D D D P */ - pd_idx = raid_disks - 1 - ((stripe + 1) % raid_disks); + stripe2 += 1; + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); qd_idx = pd_idx + 1; if (pd_idx == raid_disks-1) { (*dd_idx)++; /* Q D D D P */ @@ -1792,7 +1793,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, case ALGORITHM_ROTATING_N_CONTINUE: /* Same as left_symmetric but Q is before P */ - pd_idx = raid_disks - 1 - (stripe % raid_disks); + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); qd_idx = (pd_idx + raid_disks - 1) % raid_disks; *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; ddf_layout = 1; @@ -1800,27 +1801,27 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, case ALGORITHM_LEFT_ASYMMETRIC_6: /* RAID5 left_asymmetric, with Q on last device */ - pd_idx = data_disks - stripe % (raid_disks-1); + pd_idx = data_disks - sector_div(stripe2, raid_disks-1); if (*dd_idx >= pd_idx) (*dd_idx)++; qd_idx = raid_disks - 1; break; case ALGORITHM_RIGHT_ASYMMETRIC_6: - pd_idx = stripe % (raid_disks-1); + pd_idx = sector_div(stripe2, raid_disks-1); if (*dd_idx >= pd_idx) (*dd_idx)++; qd_idx = raid_disks - 1; break; case ALGORITHM_LEFT_SYMMETRIC_6: - pd_idx = data_disks - stripe % (raid_disks-1); + pd_idx = data_disks - sector_div(stripe2, raid_disks-1); *dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1); qd_idx = raid_disks - 1; break; case ALGORITHM_RIGHT_SYMMETRIC_6: - pd_idx = stripe % (raid_disks-1); + pd_idx = sector_div(stripe2, raid_disks-1); *dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1); qd_idx = raid_disks - 1; break; ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree 2010-04-22 2:40 ` Neil Brown @ 2010-04-22 11:36 ` Stefan Lippers-Hollmann 2010-04-23 3:11 ` Greg KH 0 siblings, 1 reply; 6+ messages in thread From: Stefan Lippers-Hollmann @ 2010-04-22 11:36 UTC (permalink / raw) To: Neil Brown; +Cc: gregkh, linux-kernel, king.br, stable Hi On Thursday 22 April 2010, Neil Brown wrote: > On Thu, 22 Apr 2010 04:08:30 +0200 > "Stefan Lippers-Hollmann" <s.L-H@gmx.de> wrote: > > On Thursday 22 April 2010, gregkh@suse.de wrote: [...] > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > > > From: NeilBrown <neilb@suse.de> > > > Date: Tue, 20 Apr 2010 14:13:34 +1000 > > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > > > From: NeilBrown <neilb@suse.de> > > > > > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > > > > > With many large drives and small chunk sizes it is possible > > > to create a RAID5 with more than 2^31 chunks. Make sure this > > > works. > > > > > > Reported-by: Brett King <king.br@gmail.com> > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > This patch, as part of the current 2.6.33 stable queue, breaks compiling > > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): > > > > [...] > > BUILD arch/x86/boot/bzImage > > Root device is (254, 6) > > Setup is 12700 bytes (padded to 12800 bytes). > > System is 2415 kB > > CRC db6fa5fa > > Kernel: arch/x86/boot/bzImage is ready (#1) > > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! > > > > reverting just this patch fixes the problem for me. > > Thanks for testing and reporting. > > If you could verify that this additional patch fixes the compile error I > would really appreciate it. I can confirm that this patch on top of the original md-raid5-allow-for-more-than-2-31-chunks.patch fixes the build problem on i386 for me (amd64 continues to build fine as well). Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Thank you a lot Stefan Lippers-Hollmann -- > Thanks, > NeilBrown > > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index 20e4840..58ea0ec 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -1650,7 +1650,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > int previous, int *dd_idx, > struct stripe_head *sh) > { > - sector_t stripe; > + sector_t stripe, stripe2; > sector_t chunk_number; > unsigned int chunk_offset; > int pd_idx, qd_idx; > @@ -1677,7 +1677,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > */ > stripe = chunk_number; > *dd_idx = sector_div(stripe, data_disks); > - > + stripe2 = stripe; > /* > * Select the parity disk based on the user selected algorithm. > */ > @@ -1689,21 +1689,21 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > case 5: > switch (algorithm) { > case ALGORITHM_LEFT_ASYMMETRIC: > - pd_idx = data_disks - stripe % raid_disks; > + pd_idx = data_disks - sector_div(stripe2, raid_disks); > if (*dd_idx >= pd_idx) > (*dd_idx)++; > break; > case ALGORITHM_RIGHT_ASYMMETRIC: > - pd_idx = stripe % raid_disks; > + pd_idx = sector_div(stripe2, raid_disks); > if (*dd_idx >= pd_idx) > (*dd_idx)++; > break; > case ALGORITHM_LEFT_SYMMETRIC: > - pd_idx = data_disks - stripe % raid_disks; > + pd_idx = data_disks - sector_div(stripe2, raid_disks); > *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; > break; > case ALGORITHM_RIGHT_SYMMETRIC: > - pd_idx = stripe % raid_disks; > + pd_idx = sector_div(stripe2, raid_disks); > *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; > break; > case ALGORITHM_PARITY_0: > @@ -1723,7 +1723,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > > switch (algorithm) { > case ALGORITHM_LEFT_ASYMMETRIC: > - pd_idx = raid_disks - 1 - (stripe % raid_disks); > + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); > qd_idx = pd_idx + 1; > if (pd_idx == raid_disks-1) { > (*dd_idx)++; /* Q D D D P */ > @@ -1732,7 +1732,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > (*dd_idx) += 2; /* D D P Q D */ > break; > case ALGORITHM_RIGHT_ASYMMETRIC: > - pd_idx = stripe % raid_disks; > + pd_idx = sector_div(stripe2, raid_disks); > qd_idx = pd_idx + 1; > if (pd_idx == raid_disks-1) { > (*dd_idx)++; /* Q D D D P */ > @@ -1741,12 +1741,12 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > (*dd_idx) += 2; /* D D P Q D */ > break; > case ALGORITHM_LEFT_SYMMETRIC: > - pd_idx = raid_disks - 1 - (stripe % raid_disks); > + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); > qd_idx = (pd_idx + 1) % raid_disks; > *dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks; > break; > case ALGORITHM_RIGHT_SYMMETRIC: > - pd_idx = stripe % raid_disks; > + pd_idx = sector_div(stripe2, raid_disks); > qd_idx = (pd_idx + 1) % raid_disks; > *dd_idx = (pd_idx + 2 + *dd_idx) % raid_disks; > break; > @@ -1765,7 +1765,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > /* Exactly the same as RIGHT_ASYMMETRIC, but or > * of blocks for computing Q is different. > */ > - pd_idx = stripe % raid_disks; > + pd_idx = sector_div(stripe2, raid_disks); > qd_idx = pd_idx + 1; > if (pd_idx == raid_disks-1) { > (*dd_idx)++; /* Q D D D P */ > @@ -1780,7 +1780,8 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > * D D D P Q rather than > * Q D D D P > */ > - pd_idx = raid_disks - 1 - ((stripe + 1) % raid_disks); > + stripe2 += 1; > + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); > qd_idx = pd_idx + 1; > if (pd_idx == raid_disks-1) { > (*dd_idx)++; /* Q D D D P */ > @@ -1792,7 +1793,7 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > > case ALGORITHM_ROTATING_N_CONTINUE: > /* Same as left_symmetric but Q is before P */ > - pd_idx = raid_disks - 1 - (stripe % raid_disks); > + pd_idx = raid_disks - 1 - sector_div(stripe2, raid_disks); > qd_idx = (pd_idx + raid_disks - 1) % raid_disks; > *dd_idx = (pd_idx + 1 + *dd_idx) % raid_disks; > ddf_layout = 1; > @@ -1800,27 +1801,27 @@ static sector_t raid5_compute_sector(raid5_conf_t *conf, sector_t r_sector, > > case ALGORITHM_LEFT_ASYMMETRIC_6: > /* RAID5 left_asymmetric, with Q on last device */ > - pd_idx = data_disks - stripe % (raid_disks-1); > + pd_idx = data_disks - sector_div(stripe2, raid_disks-1); > if (*dd_idx >= pd_idx) > (*dd_idx)++; > qd_idx = raid_disks - 1; > break; > > case ALGORITHM_RIGHT_ASYMMETRIC_6: > - pd_idx = stripe % (raid_disks-1); > + pd_idx = sector_div(stripe2, raid_disks-1); > if (*dd_idx >= pd_idx) > (*dd_idx)++; > qd_idx = raid_disks - 1; > break; > > case ALGORITHM_LEFT_SYMMETRIC_6: > - pd_idx = data_disks - stripe % (raid_disks-1); > + pd_idx = data_disks - sector_div(stripe2, raid_disks-1); > *dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1); > qd_idx = raid_disks - 1; > break; > > case ALGORITHM_RIGHT_SYMMETRIC_6: > - pd_idx = stripe % (raid_disks-1); > + pd_idx = sector_div(stripe2, raid_disks-1); > *dd_idx = (pd_idx + 1 + *dd_idx) % (raid_disks-1); > qd_idx = raid_disks - 1; > break; > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree 2010-04-22 11:36 ` Stefan Lippers-Hollmann @ 2010-04-23 3:11 ` Greg KH 2010-04-23 11:13 ` Neil Brown 2010-04-23 11:53 ` Stefan Lippers-Hollmann 0 siblings, 2 replies; 6+ messages in thread From: Greg KH @ 2010-04-23 3:11 UTC (permalink / raw) To: Stefan Lippers-Hollmann; +Cc: Neil Brown, linux-kernel, king.br, stable On Thu, Apr 22, 2010 at 01:36:26PM +0200, Stefan Lippers-Hollmann wrote: > Hi > > On Thursday 22 April 2010, Neil Brown wrote: > > On Thu, 22 Apr 2010 04:08:30 +0200 > > "Stefan Lippers-Hollmann" <s.L-H@gmx.de> wrote: > > > On Thursday 22 April 2010, gregkh@suse.de wrote: > [...] > > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > > > > From: NeilBrown <neilb@suse.de> > > > > Date: Tue, 20 Apr 2010 14:13:34 +1000 > > > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > > > > > From: NeilBrown <neilb@suse.de> > > > > > > > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > > > > > > > With many large drives and small chunk sizes it is possible > > > > to create a RAID5 with more than 2^31 chunks. Make sure this > > > > works. > > > > > > > > Reported-by: Brett King <king.br@gmail.com> > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > This patch, as part of the current 2.6.33 stable queue, breaks compiling > > > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): > > > > > > [...] > > > BUILD arch/x86/boot/bzImage > > > Root device is (254, 6) > > > Setup is 12700 bytes (padded to 12800 bytes). > > > System is 2415 kB > > > CRC db6fa5fa > > > Kernel: arch/x86/boot/bzImage is ready (#1) > > > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! > > > > > > reverting just this patch fixes the problem for me. > > > > Thanks for testing and reporting. > > > > If you could verify that this additional patch fixes the compile error I > > would really appreciate it. > > I can confirm that this patch on top of the original > md-raid5-allow-for-more-than-2-31-chunks.patch fixes the build problem on > i386 for me (amd64 continues to build fine as well). > > Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Neil, care to push this to Linus? thanks, greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree 2010-04-23 3:11 ` Greg KH @ 2010-04-23 11:13 ` Neil Brown 2010-04-23 11:53 ` Stefan Lippers-Hollmann 1 sibling, 0 replies; 6+ messages in thread From: Neil Brown @ 2010-04-23 11:13 UTC (permalink / raw) To: Greg KH; +Cc: Stefan Lippers-Hollmann, linux-kernel, king.br, stable On Thu, 22 Apr 2010 20:11:00 -0700 Greg KH <gregkh@suse.de> wrote: > On Thu, Apr 22, 2010 at 01:36:26PM +0200, Stefan Lippers-Hollmann wrote: > > Hi > > > > On Thursday 22 April 2010, Neil Brown wrote: > > > On Thu, 22 Apr 2010 04:08:30 +0200 > > > "Stefan Lippers-Hollmann" <s.L-H@gmx.de> wrote: > > > > On Thursday 22 April 2010, gregkh@suse.de wrote: > > [...] > > > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > > > > > From: NeilBrown <neilb@suse.de> > > > > > Date: Tue, 20 Apr 2010 14:13:34 +1000 > > > > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > > > > > > > From: NeilBrown <neilb@suse.de> > > > > > > > > > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > > > > > > > > > With many large drives and small chunk sizes it is possible > > > > > to create a RAID5 with more than 2^31 chunks. Make sure this > > > > > works. > > > > > > > > > > Reported-by: Brett King <king.br@gmail.com> > > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > > > This patch, as part of the current 2.6.33 stable queue, breaks compiling > > > > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): > > > > > > > > [...] > > > > BUILD arch/x86/boot/bzImage > > > > Root device is (254, 6) > > > > Setup is 12700 bytes (padded to 12800 bytes). > > > > System is 2415 kB > > > > CRC db6fa5fa > > > > Kernel: arch/x86/boot/bzImage is ready (#1) > > > > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! > > > > > > > > reverting just this patch fixes the problem for me. > > > > > > Thanks for testing and reporting. > > > > > > If you could verify that this additional patch fixes the compile error I > > > would really appreciate it. > > > > I can confirm that this patch on top of the original > > md-raid5-allow-for-more-than-2-31-chunks.patch fixes the build problem on > > i386 for me (amd64 continues to build fine as well). > > > > Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> > > Neil, care to push this to Linus? I've sent him a request to pull it from git://neil.brown.name/md for-linus Thanks. NeilBrown ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree 2010-04-23 3:11 ` Greg KH 2010-04-23 11:13 ` Neil Brown @ 2010-04-23 11:53 ` Stefan Lippers-Hollmann 1 sibling, 0 replies; 6+ messages in thread From: Stefan Lippers-Hollmann @ 2010-04-23 11:53 UTC (permalink / raw) To: Greg KH; +Cc: Neil Brown, linux-kernel, king.br, stable Hi On Friday 23 April 2010, Greg KH wrote: > On Thu, Apr 22, 2010 at 01:36:26PM +0200, Stefan Lippers-Hollmann wrote: > > Hi > > > > On Thursday 22 April 2010, Neil Brown wrote: > > > On Thu, 22 Apr 2010 04:08:30 +0200 > > > "Stefan Lippers-Hollmann" <s.L-H@gmx.de> wrote: > > > > On Thursday 22 April 2010, gregkh@suse.de wrote: > > [...] > > > > > From 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Mon Sep 17 00:00:00 2001 > > > > > From: NeilBrown <neilb@suse.de> > > > > > Date: Tue, 20 Apr 2010 14:13:34 +1000 > > > > > Subject: md/raid5: allow for more than 2^31 chunks. > > > > > > > > > > From: NeilBrown <neilb@suse.de> > > > > > > > > > > commit 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d upstream. > > > > > > > > > > With many large drives and small chunk sizes it is possible > > > > > to create a RAID5 with more than 2^31 chunks. Make sure this > > > > > works. > > > > > > > > > > Reported-by: Brett King <king.br@gmail.com> > > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > > > This patch, as part of the current 2.6.33 stable queue, breaks compiling > > > > on i386 (CONFIG_LBDAF=y) for me (amd64 builds fine): > > > > > > > > [...] > > > > BUILD arch/x86/boot/bzImage > > > > Root device is (254, 6) > > > > Setup is 12700 bytes (padded to 12800 bytes). > > > > System is 2415 kB > > > > CRC db6fa5fa > > > > Kernel: arch/x86/boot/bzImage is ready (#1) > > > > ERROR: "__umoddi3" [drivers/md/raid456.ko] undefined! > > > > > > > > reverting just this patch fixes the problem for me. > > > > > > Thanks for testing and reporting. > > > > > > If you could verify that this additional patch fixes the compile error I > > > would really appreciate it. > > > > I can confirm that this patch on top of the original > > md-raid5-allow-for-more-than-2-31-chunks.patch fixes the build problem on > > i386 for me (amd64 continues to build fine as well). > > > > Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> > > Neil, care to push this to Linus? Gitweb: http://git.kernel.org/linus/6e3b96ed610e5a1838e62ddae9fa0c3463f235fa Commit: 6e3b96ed610e5a1838e62ddae9fa0c3463f235fa Parent: 35f2a591192d0a5d9f7fc696869c76f0b8e49c3d Author: NeilBrown <neilb@suse.de> AuthorDate: Fri Apr 23 07:08:28 2010 +1000 Committer: NeilBrown <neilb@suse.de> CommitDate: Fri Apr 23 07:08:28 2010 +1000 md/raid5: fix previous patch. Previous patch changes stripe and chunk_number to sector_t but mistakenly did not update all of the divisions to use sector_dev(). This patch changes all the those divisions (actually the '%' operator) to sector_div. Signed-off-by: NeilBrown <neilb@suse.de> Cc: stable@kernel.org Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Regards Stefan Lippers-Hollmann ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-23 11:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <12718801381479@kroah.org>
2010-04-22 2:08 ` patch md-raid5-allow-for-more-than-2-31-chunks.patch added to 2.6.33-stable tree Stefan Lippers-Hollmann
2010-04-22 2:40 ` Neil Brown
2010-04-22 11:36 ` Stefan Lippers-Hollmann
2010-04-23 3:11 ` Greg KH
2010-04-23 11:13 ` Neil Brown
2010-04-23 11:53 ` Stefan Lippers-Hollmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox