Re: [Jfs-discussion] jfs volume fubared when resizing LVM

[Dave K. <sh...@li...>]

On Tue, 2007-01-23 at 21:53 +0100, Simon Lundell wrote:
> Hi all!
> 
> Once again I have problems with JFS, and once again, the fault is
> probably mine. This time I tried to extend a LVM volume group and
> remount the jfs volume with the resize option. However, I might have
> entered the commands in the wrong order.

That shouldn't have caused any corruption.  I don't think there's any
way that LVM would have reported too large a size for the LV, and as
long as you never shrunk the LV then it should have been okay.

> That is I first did a vgextend,
> and then resized the jfsvolume. I should have run lvextend before
> resizing jfs.

Then the resize shouldn't have done anything.  JFS shouldn't grow the
file system bigger than the volume size.

> So i did lvextend without a problem, then resized again.

This should have worked.

> All seemed fine, except that the filesystem was remounted read-only.
> Now, I am not able to fsck the filesystem. Output from fsck is attached.
> Is it possible to rescue this filesystem?

Probably not.  I'm not sure what went wrong, but it looks pretty messed
up.

> I am able to read the files,
> so I might be able to backup everything, rebuild the lvm and jfs and
> then move it back.

That is what I would advise.  Hopefully you'll be able to read
everything okay.

It's been a while since I played with resize.  I'll try to find some
time to do put it though some testing to see if I can reproduce
something like this.  Oh, what is your kernel version?

> Best regards,
> Simon
> 
> 
> 
> simons ~ # fsck  -dvf /dev/vgmedia/media
> fsck 1.39 (29-May-2006)
> fsck.jfs version 1.1.11, 05-Jun-2006
> processing started: 1/23/2007 21.51.9
> The current device is:  /dev/vgmedia/media [xchkdsk.c:1520]
> Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 [fsckpfs.c:3233]
> Primary superblock is valid. [fsckmeta.c:1551]
> The type of file system for the device is JFS. [xchkdsk.c:1537]
> Block size in bytes:  4096 [xchkdsk.c:1850]
> Filesystem size in blocks:  102028288 [xchkdsk.c:1857]
> **Phase 0 - Replay Journal Log [xchkdsk.c:1864]
> LOGREDO:  Log superblock contains invalid magic number. [logredo.c:529]
> logredo failed (rc=-268).  fsck continuing. [xchkdsk.c:1894]

bad.  I don't know what happened to your journal, but the superblock,
which sits at the beginning of it is corrupt.

> **Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
> [xchkdsk.c:1989]
> Primary metadata inode A2 is corrupt. [fsckmeta.c:3170]
> Duplicate reference to 12471 block(s) beginning at offset 16 found in
> file system object MA2. [fsckwsp.c:452]

Worse.  The block allocation map is using space that some other object
also claims to use.  The good news is that the block map isn't needed
for read-only operations.

> Inode A2 has references to cross linked blocks. [fsckwsp.c:1772]
> Errors detected in the Primary File/Directory Allocation Table.
> [fsckmeta.c:1890]
> Errors detected in the Secondary File/Directory Allocation Table.
> [fsckmeta.c:1895]
> CANNOT CONTINUE. [fsckmeta.c:1902]
> processing terminated:  1/23/2007 21:51:09  with return code: -10049
> exit code: 4. [xchkdsk.c:468]

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center