On Wed, 2005-08-03 at 13:12 -0700, Will wrote:

> > The beginning of the superblock has enough
> > resemblance to a correct
> > superblock to make it look like you have the right
> > blocks, but there is
> > too much wrong.  I know very little about raid. 
> > Could you be using
> > raid3 or raid7?  I think the use of byte-size
> > striping may explain the
> > problem if all 5 disks aren't ordered properly.
> > 
> 
> Alright, if everything look pretty much wrong, then I
> image the disks are not in the correct order. I know
> for certain that the drives were a raid 5, and they
> have the proper stripe size (128K), and I am certain I
> have the proper first disk (the partition table only
> shows us when one specific disk is in a certain
> position). I guess what I will do is try each of the
> 24 different combinations and record the primary and
> secondary superblock data for each configuration.

I'm trying to learn a little about raid and figure out why some of the
data in the superblock seems close to the right data.  What if instead
of the proper block from disk x, you are looking at the parity block on
disk y instead?  If the other 3 blocks which determine the parity are
mostly zeroed, some fields may be close enough to the 4th block to be
recognizable, but there is enough data there to mess up the rest of the
block.  This is just a silly theory, but it seems possible.

> Is there anything specific I should look for in the
> superblock information to give me an idea that I am on
> the right track? A parameter that should only have a
> small range of values, or a specific value? 

Here's a sane superblock.  I'll try to point out the things I expect to
always be fixed.

Hmm.  Both superblocks will reside on the first 128K stripe, so even if
both superblocks look right, some other disks may be out of order.

> sup
[1] s_magic:            'JFS1'          [15] s_ait2.addr1:      0x00
[2] s_version:          1               [16] s_ait2.addr2:      0x000001b7
[3] s_size:     0x00000000019f2fa8           s_ait2.address:    439
[4] s_bsize:            4096            [17] s_logdev:          0x0000030b
[5] s_l2bsize:          12              [18] s_logserial:       0x00000019
[6] s_l2bfactor:        3               [19] s_logpxd.len:      8192
[7] s_pbsize:           512             [20] s_logpxd.addr1:    0x00
[8] s_l2pbsize:         9               [21] s_logpxd.addr2:    0x0033e690
[9] pad:                Not Displayed        s_logpxd.address:  3401360
[10] s_agsize:          0x00008000      [22] s_fsckpxd.len:     155
[11] s_flag:            0x10200900      [23] s_fsckpxd.addr1:   0x00
                        JFS_LINUX       [24] s_fsckpxd.addr2:   0x0033e5f5
        JFS_COMMIT      JFS_GROUPCOMMIT      s_fsckpxd.address: 3401205
                        JFS_INLINELOG   [25] s_time.tv_sec:     0x42dfbf0c
                                        [26] s_time.tv_nsec:    0x00000000
                                        [27] s_fpack:           ''
[12] s_state:           0x00000000
             FM_CLEAN
[13] s_compress:        0
[14] s_ait2.len:        4

s_magic will always be 'JFS1'.
s_version will probably be 1, but can be 2.
Fields 4-8 should always be as shown above.
s_agsize will always be a power of 2.
s_flag will probably be as shown.
s_state should be 0, 1, or 2.
s_compress should be 0
s_ait2.len should be 4.
I think s_ait2.address is always the same, but I'm not positive.

> Again, I thank you so much for your help so far!

Good luck.  Getting a good superblock may not guarantee that all the
disks are ordered correctly.  But it should help you narrow down the
possibilities.

> > > display_super: [m]odify or e[x]it: x
> > > > s2p
> > 
> > s2p is kind of silly in that it mostly prints the
> > same stuff.  "sup s"
> > will print the secondary superblock.
> 
> I will make sure I print the secondary superblock
> instead.
> 
> > -- 
> > David Kleikamp
> > IBM Linux Technology Center
> 
> 
> 
>               
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
> 
-- 
David Kleikamp
IBM Linux Technology Center



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to