public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: kevin.dual@gmail.com
To: xfs@oss.sgi.com
Subject: Re: Power loss causes bad magic number??
Date: Sat, 7 Feb 2009 15:46:01 -0500	[thread overview]
Message-ID: <22271900.11234039561556.JavaMail.root@wombat.diezmil.com> (raw)
In-Reply-To: <F46A887185FC6044A7FAC577E31118AE022316C0@rsbne01.RSBNE.LOCAL>

I'm having a very similar problem... My 1TB RAID-5 array formatted with XFS assembles, but refuses to mount:

--------------------------------------------------
$ dmesg
...
[19827.704838] XFS: bad magic number
[19827.704847] XFS: SB validate failed

--------------------------------------------------
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

--------------------------------------------------
$ sudo parted -l
Model: ATA ST3500641AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size    Type      File system  Flags
 1      32.3kB  480GB  480GB   primary   ext3         boot
 2      480GB   500GB  20.3GB  extended
 5      480GB   500GB  20.3GB  logical   linux-swap


Model: ATA ST3500641AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  500GB  500GB  primary               raid


Model: ATA ST3500641AS (scsi)
Disk /dev/sdc: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  500GB  500GB  primary               raid


Model: ATA ST3500641AS (scsi)
Disk /dev/sdd: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  500GB  500GB  primary               raid


Error: /dev/md0: unrecognised disk label

--------------------------------------------------
$ sudo xfs_check /dev/md0
xfs_check: unexpected XFS SB magic number 0x110812af
cache_node_purge: refcount was 1, not zero (node=0x1300220)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x1300440)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault

$ sudo xfs_check /dev/sdb1
xfs_check: unexpected XFS SB magic number 0x110812af
cache_node_purge: refcount was 1, not zero (node=0x2213220)
xfs_check: cannot read root inode (22)
bad superblock magic number 110812af, giving up

$ sudo xfs_check /dev/sdc1
cache_node_purge: refcount was 1, not zero (node=0x2377220)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x2377440)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault

$ sudo xfs_check /dev/sdd1
xfs_check: unexpected XFS SB magic number 0x494e41ed
xfs_check: size check failed
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
cache_node_purge: refcount was 1, not zero (node=0x24f1c20)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x24f1d70)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault


--------------------------------------------------
$ sudo xfs_repair -n /dev/md0
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
...etc...etc...fail fail fail

$ sudo xfs_repair -n /dev/sdb1
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
...etc...etc...fail fail fail

$ sudo xfs_repair -n /dev/sdc1
Phase 1 - find and verify superblock...                
error reading superblock 17 -- seek to offset 531361234944 failed
couldn't verify primary superblock - bad magic number !!!        

attempting to find secondary superblock...
...found candidate secondary superblock...
error reading superblock 17 -- seek to offset 531361234944 failed                                                                                                                                                                                                              
unable to verify superblock, continuing...              
...etc...etc...fail fail fail

you know the routine... 


--------------------------------------------------
$ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s

$ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s

$ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
00007e00  58 46 53 42 00 00 10 00  00 00 00 00 0e 8e 12 00  |XFSB............|
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s

$ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s

Looks like /dev/sdc is the only one with any recognizable superblock data on it.
--------------------------------------------------

Now what should I do with all this information?  The array assembles fine, but the XFS volume seems to be screwed up somehow.  Is there any way the array could have put itself together wrong then re-synced and corrupted all my data?


--
This message was sent on behalf of kevin.dual@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/xfs@oss.sgi.com/9638260.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2009-02-07 20:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16  2:18 Power loss causes bad magic number?? Stephen Porter
2008-07-16  2:40 ` Eric Sandeen
2008-07-16  7:01   ` Stephen Porter
2008-07-16  7:35     ` Dave Chinner
2008-07-16  8:17       ` Stephen Porter
2008-07-16 16:00         ` Chris Wedgwood
2008-07-17 13:36         ` Russell Cattelan
2008-07-17 21:52           ` Stephen Porter
2008-07-18 11:17             ` Andi Kleen
2008-07-18 18:19         ` Peter Grandi
2009-02-07 20:46 ` kevin.dual [this message]
2009-02-07 21:10   ` Eric Sandeen
2009-02-07 21:54     ` Eric Sandeen
2009-02-08  6:10     ` Kevin Dual

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=22271900.11234039561556.JavaMail.root@wombat.diezmil.com \
    --to=kevin.dual@gmail.com \
    --cc=xfs@oss.sgi.com \
    /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