linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).