From: Bill Davidsen <davidsen@tmr.com>
To: Neil Brown <neilb@suse.de>
Cc: "Mr. James W. Laferriere" <babydr@baby-dragons.com>,
linux-raid maillist <linux-raid@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: mdadm: RUN_ARRAY failed: Cannot allocate memory
Date: Fri, 30 Mar 2007 12:37:25 -0400 [thread overview]
Message-ID: <460D3CC5.10004@tmr.com> (raw)
In-Reply-To: <17931.28833.443823.720207@notabene.brown>
Neil Brown wrote:
> On Saturday March 24, babydr@baby-dragons.com wrote:
>
>> Hello Neil , I found the problem that caused the 'cannot allcate
>> memory' , DON'T use '--bitmap=' .
>> But that said , Hmmmm , Shouldn't mdadm just stop & say ...
>> 'md: bitmaps not supported for this level.'
>> Like it puts out into dmesg .
>>
>> Also think this message in dmesg is interesting .
>> "raid0: bad disk number -1 - aborting!'
>>
>> Hth , JimL
>>
>
> Yeah.... mdadm should be fixed too, but this kernel patch should make
> it behave a bit better. I'll queue it for 2.6.22.
>
Given the release cycle, this might fit 2.6.21-rc6 (is is a fix), or
stable 2.6.21.1 if 21 comes out soon. In any case it could go in -mm for
testing and to be sure it would be pushed at an appropriate time.
> Thanks,
> NeilBrown
>
>
> Move test for whether level supports bitmap to correct place.
>
> We need to check for internal-consistency of superblock in
> load_super. validate_super is for inter-device consistency.
>
>
> Signed-off-by: Neil Brown <neilb@suse.de>
>
> ### Diffstat output
> ./drivers/md/md.c | 42 ++++++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff .prev/drivers/md/md.c ./drivers/md/md.c
> --- .prev/drivers/md/md.c 2007-03-29 16:42:18.000000000 +1000
> +++ ./drivers/md/md.c 2007-03-29 16:49:26.000000000 +1000
> @@ -695,6 +695,17 @@ static int super_90_load(mdk_rdev_t *rde
> rdev->data_offset = 0;
> rdev->sb_size = MD_SB_BYTES;
>
> + if (sb->state & (1<<MD_SB_BITMAP_PRESENT)) {
> + if (sb->level != 1 && sb->level != 4
> + && sb->level != 5 && sb->level != 6
> + && sb->level != 10) {
> + /* FIXME use a better test */
> + printk(KERN_WARNING
> + "md: bitmaps not supported for this level.\n");
> + goto abort;
> + }
> + }
> +
> if (sb->level == LEVEL_MULTIPATH)
> rdev->desc_nr = -1;
> else
> @@ -793,16 +804,8 @@ static int super_90_validate(mddev_t *md
> mddev->max_disks = MD_SB_DISKS;
>
> if (sb->state & (1<<MD_SB_BITMAP_PRESENT) &&
> - mddev->bitmap_file == NULL) {
> - if (mddev->level != 1 && mddev->level != 4
> - && mddev->level != 5 && mddev->level != 6
> - && mddev->level != 10) {
> - /* FIXME use a better test */
> - printk(KERN_WARNING "md: bitmaps not supported for this level.\n");
> - return -EINVAL;
> - }
> + mddev->bitmap_file == NULL)
> mddev->bitmap_offset = mddev->default_bitmap_offset;
> - }
>
> } else if (mddev->pers == NULL) {
> /* Insist on good event counter while assembling */
> @@ -1059,6 +1062,18 @@ static int super_1_load(mdk_rdev_t *rdev
> bdevname(rdev->bdev,b));
> return -EINVAL;
> }
> + if ((le32_to_cpu(sb->feature_map) & MD_FEATURE_BITMAP_OFFSET)) {
> + if (sb->level != cpu_to_le32(1) &&
> + sb->level != cpu_to_le32(4) &&
> + sb->level != cpu_to_le32(5) &&
> + sb->level != cpu_to_le32(6) &&
> + sb->level != cpu_to_le32(10)) {
> + printk(KERN_WARNING
> + "md: bitmaps not supported for this level.\n");
> + return -EINVAL;
> + }
> + }
> +
> rdev->preferred_minor = 0xffff;
> rdev->data_offset = le64_to_cpu(sb->data_offset);
> atomic_set(&rdev->corrected_errors, le32_to_cpu(sb->cnt_corrected_read));
> @@ -1142,14 +1157,9 @@ static int super_1_validate(mddev_t *mdd
> mddev->max_disks = (4096-256)/2;
>
> if ((le32_to_cpu(sb->feature_map) & MD_FEATURE_BITMAP_OFFSET) &&
> - mddev->bitmap_file == NULL ) {
> - if (mddev->level != 1 && mddev->level != 5 && mddev->level != 6
> - && mddev->level != 10) {
> - printk(KERN_WARNING "md: bitmaps not supported for this level.\n");
> - return -EINVAL;
> - }
> + mddev->bitmap_file == NULL )
> mddev->bitmap_offset = (__s32)le32_to_cpu(sb->bitmap_offset);
> - }
> +
> if ((le32_to_cpu(sb->feature_map) & MD_FEATURE_RESHAPE_ACTIVE)) {
> mddev->reshape_position = le64_to_cpu(sb->reshape_position);
> mddev->delta_disks = le32_to_cpu(sb->delta_disks);
>
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
prev parent reply other threads:[~2007-03-30 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 4:41 Another report of a raid6 array being maintaind by _raid5 in ps Mr. James W. Laferriere
2007-03-22 5:30 ` Neil Brown
2007-03-22 13:45 ` Bill Davidsen
2007-03-24 19:26 ` mdadm: RUN_ARRAY failed: Cannot allocate memory Mr. James W. Laferriere
2007-03-29 7:54 ` Neil Brown
2007-03-30 16:37 ` Bill Davidsen [this message]
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=460D3CC5.10004@tmr.com \
--to=davidsen@tmr.com \
--cc=akpm@linux-foundation.org \
--cc=babydr@baby-dragons.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).