linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eli Stair <estair@ilm.com>
To: Eli Stair <estair@ilm.com>
Cc: linux-raid mailing list <linux-raid@vger.kernel.org>
Subject: Re: BUGS: internal bitmap during array create
Date: Thu, 12 Oct 2006 18:02:17 -0700	[thread overview]
Message-ID: <452EE599.8030200@ilm.com> (raw)
In-Reply-To: <452D500D.6000203@ilm.com>


As of NeilB's release a few minutes ago, this issue is still occuring. 
Looks like the XFS superblock isn't being written properly or is 
corrupted upon read:

/// xfs_repair can't validate superblock:

     [root@gtmp04 ~]# xfs_repair /dev/md0
     Phase 1 - find and verify superblock...
     bad primary superblock - bad magic number !!!
     attempting to find secondary superblock...



/// xfs_check doesn't like superblock magic:

     [root@gtmp04 ~]# xfs_check -v /dev/md0
     xfs_check: unexpected XFS SB magic number 0x00000000
     xfs_check: read failed: Invalid argument
     xfs_check: data size check failed


Thanks!

/eli


Eli Stair wrote:
> 
> After realizing my stupid error in specifying the bitmap during array
> creation, I've triggered a couple of 100% repeatable bugs with this
> scenario.
> 
> 
> BUG 1)
> 
> When I create an array without a bitmap and add it after the array is
> synced, all works fine with any filesystem.  If I create WITH the
> internal bitmap and use xfs, it chokes at mount time with:
> 
>      mount: wrong fs type, bad option, bad superblock on /dev/md0,
>      or too many mounted file systems
> 
> xfs_check also dies with:
> 
>      [root@gtmp01 GTMP]# xfs_check /dev/md0
>      xfs_check: unexpected XFS SB magic number 0x00000000
>      xfs_check: read failed: Invalid argument
>      xfs_check: data size check failed
>      /usr/sbin/xfs_check: line 28: 30580 Segmentation fault
> xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
> 
> 
> Strangely, whatever the underlying cause is, ext3 seems immune (at least
> in brief testing) to this.  I can create and mount an ext3 filesystem on
> top of the array that xfs dies trying to mount.
> 
> In the case where the array is created with bitmap at build time, if I
> wait until resync is completed, do a 'mdadm -Gb none' followed by 'mdadm
> -Gb internal', I can then safely create the XFS filesystem and mount it.
> 
> BUG 2)
> 
> Another bitmap failure during create time:  MDADM dies with an error
> after creating the array, when it tries to assemble it, with an
> external-file bitmap (on ext3):
> 
> 
>      [root@gtmp01 GTMP]# mdadm -C /dev/md0 -f --chunk=512 --level=10
> -n14 -po2 -e1.2 -bESC[1P^M[root@gtmp01 GTMP]# mdadm -C /dev/md0 -f
> --chunk=512 --level=10 -n14 -po2 -e1.2 -b/var/tmp/bitmap /dev/mapper/mpath*
>      mdadm: RUN_ARRAY failed: Cannot allocate memory
>      mdadm: stopped /dev/md0
> 
> 
> The array can be manually assembled, but it does not load with the
> bitmap, even when specifying it with 'mdadm -A /dev/md0 -b/var/tmp/bitmap'.
> 
> 
> 
> 
> For reference, I'm running:
> 
> mdadm - v2.5.3 -  7 August 2006
> mkfs.xfs version 2.8.11
> kernel 2.6.18 (Opteron, x86_64, SMP)
> 
> 
> I've attached typescript of the sessions where I run through all of
> these scenarios, as well as an strace of the "mdadm -C
> -b/var/tmp/bitmap" where it fails to assemble the array.  Also is a file
> with the superblock detail on all the member devices.
> 
> Again, more than happy to help test patches and any scenarios.
> 
> Cheers,
> 
> /eli
> 


  reply	other threads:[~2006-10-13  1:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11 20:11 BUGS: internal bitmap during array create Eli Stair
2006-10-13  1:02 ` Eli Stair [this message]
2006-10-13  2:48 ` Neil Brown
2006-10-18 23:26   ` Eli Stair
2006-10-19  6:50     ` Neil Brown
2006-10-19 23:34       ` Eli Stair
2006-10-20  0:30         ` Neil Brown

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=452EE599.8030200@ilm.com \
    --to=estair@ilm.com \
    --cc=linux-raid@vger.kernel.org \
    /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).