filesystems corrupt (superblock dirty)

[ecollard]

Hi,
i have a filesystems JFS2 with 250.000.000 files and when i try to mount it, i have :
mount /ARCHIVES
mount: /dev/lvarchives on /ARCHIVES: Unformatted or incompatible media
The superblock on /dev/lvarchives is dirty. Run a full fsck to fix.

but with any files, i wait but the fsck not finish and occuped many memory
I have this :
The current volume is: /dev/lvarchives
Primary superblock is valid.
J2_LOGREDO:log redo processing for /dev/lvarchives
logredo start at: 1149095948 sec and end at 1149095948 sec
Primary superblock is valid.
*** Phase 1 - Initial inode scan

I understand that "the scan" of the FS JFS2 with a lot of files is very long.
I think that my filesystem is in state OK,
do you have an idea to force the state to OK of the FS (perhaps the superblock) for mounting the FS without the fsck fix.

Thanks a lot

collard_bovy_e@hotmail.com

 

[mrn]

I'd wait for it to finish; It may find "other" problems.

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

http://www.airport-parking-site.co.uk/

 

[hirschaj]

You can just manually copy the backup superblock over the primary suing the following command...

dd count=1 bs=4k skip=31 seek=1 if=/dev/lvarchives of=/dev/lvarchives


Jim Hirschauer

http://www.aixexpert.com

 

[ecollard]

Thank hirschaj
are you sure that for instruction in AIX 5.3 and JFS2 ?
After i retry an fsck ?

 

[mrn]

The fsck above says the Primary superblock is valid. So copying secondary superblock "which may be corrupt" could do more damage than good. You can compare the superblocks as follows

# With root authority, use the od command to display the superblock for the file system, as shown in the following example:

od -x -N 64 /dev/lvarchives +0x1000

Where the -x flag displays output in hexadecimal format and the -N flag instructs the system to format no more than 64 input bytes from the offset parameter (+), which specifies the point in the file where the file output begins. The following is an example output:

0001000 1234 0234 0000 0000 0000 4000 0000 000a
0001010 0001 8000 1000 0000 2f6c 7633 0000 6c76
0001020 3300 0000 000a 0003 0100 0000 2f28 0383
0001030 0000 0001 0000 0200 0000 2000 0000 0000
0001040

In the preceding output, note the corrupted magic value at 0x1000 (1234 0234). If all defaults were taken when the file system was created, the magic number should be 0x43218765. If any defaults were overridden, the magic number should be 0x65872143.
# Use the od command to check the secondary superblock for a correct magic number. An example command and its output follows:

$ od -x -N 64 /dev/lvarchives +0x1f000
001f000 6587 2143 0000 0000 0000 4000 0000 000a
001f010 0001 8000 1000 0000 2f6c 7633 0000 6c76
001f020 3300 0000 000a 0003 0100 0000 2f28 0383
001f030 0000 0001 0000 0200 0000 2000 0000 0000
001f040

Note the correct magic value at 0x1f000.

If and only if this checks out do

# Copy the secondary superblock to the primary superblock. An example command and output follows:

$ dd count=1 bs=4k skip=31 seek=1 if=/dev/lv02 of=/dev/lv02
dd: 1+0 records in.
dd: 1+0 records out.

# Use the fsck command to clean up inconsistent files caused by using the secondary superblock. For example:

fsck /dev/lv02 2>&1 | tee /tmp/fsck.errs

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

http://www.airport-parking-site.co.uk/

 

[ecollard]

i tests that in a few minutes
but the beginning of the order fsck says that the superblock is valid.
I am afraid that by replace it, that does not change anything and that the scan of inode table is too long and takes too much memory.
do know you how much takes in memory an inode during a fcsk
so that I calculation how much it will be necessary of memory for fsck to finish the scan?

 

[mrn]

That should have been

dd count=1 bs=4k skip=31 seek=1 if=/dev/lvarchives of=/dev/lvarchives

&

fsck /dev/lvarchives 2>&1 | tee /tmp/fsck.errs

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

http://www.airport-parking-site.co.uk/

 

[hirschaj]

Here is the link that this info is coming from so you can reference it in the future...

http://publib.boulder.ibm.com/infoc...c/infocenter/howto/HT_baseadmn_badmagnumb.htm

Jim Hirschauer

http://www.aixexpert.com

 

[mrn]

I could have sworn I included that in my original post.... Thanks Jim

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant."

http://www.airport-parking-site.co.uk/

 

[ecollard]

I have a bad news for today:
I called before the POST hotmine IBM and they say that I must await the end of my first fsck (my 1st post) and to see with them after (and to send a snap to them)
I do not dare to stop the fsck because that made 3h that it work (6Go in memory and it always grows bigger) and I am afraid to still lose much time
What do you think : i stop it and try your solution ?

 

[kHz]

If you stop an fsck in the middle of a run there will be child processes of the fsck that you would have to kill. I can think of 'fsshop' or something like that, maybe 'fshop' that has to be killed. There may be others.

But I would personally let it finish even though it will take a long time.

 

[donzg]

Have you tried running a logform on the log file?