> 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. >
I imagine narrowing down the possibilities is pretty much all I can do. I figure if I can get the superblock correct at least, then I will be able to run fsck, and I image if I run fsck with the option -n, I won't damage anything, but perhaps tell if the order is incorrect. After that I can try mounting the file system read only, and from there I can check some of the files to see if they look correct (I have a number of files larger than 128k, so I should be able to detect an incorrect disk ordering fairly easy). Either way, your example of a correct superblock will prove very valuable. > > > > 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 > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- 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
