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
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.