I tried copying in the fresh superblock and ended up with this. Anything else?
It about 10 days worth of computing on there, so I'm only spending another few hours
on it before we just regenerate it all.


[EMAIL PROTECTED] ~]# fsck.jfs -f /dev/VolGroup00/lvol0 fsck.jfs version 1.1.7, 22-Jul-2004
processing started: 1/27/2005 13.49.9
The current device is: /dev/VolGroup00/lvol0
Superblock is corrupt and cannot be repaired
since both primary and secondary copies are corrupt.


 CANNOT CONTINUE.

On Jan 27, 2005, at 9:16 AM, Dave Kleikamp wrote:

If you want to try to fix the superblock, you can create a sparse file
that is the same size as the volume:

dd if=/dev/zero of=/somefile bs=4096 seek=1172111359 count=1

Then run "mkfs -tjfs /somefile"

Then copy the superblock:
dd if=/somefile of=/dev/VolGroup00/lvol0 bs=4096 skip=8 seek=8 count=1

I can't guarantee how much further fsck will get, but it may be worth a
try.

On Wed, 2005-01-26 at 18:37 -0600, Sean Murphy wrote:

Ok, I put the output of sup s below. It does look pretty random. But
if
I do jfs_debug a d 8 I can recognize directory names in the blocks. So
the data isn't completely trashed.

d 8 should show you the superblock, so directory names here would be a problem. But then again, jfs_debug bases this on the block size s_bsize, so who knows where it's reading from.

I'd be happy to give you a login on this machine if you want to try to
debug it.

Let me know if fixing the superblock makes any progress. -- David Kleikamp IBM Linux Technology Center

Sean Murphy
[EMAIL PROTECTED]

_______________________________________________
Jfs-discussion mailing list
[email protected]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion

Reply via email to