fsck read failure on full fsck - HELP

[Roland Rebstock_1]

Can I force mount a filesystem? Im getting a error when trying to mount a filesystem stating its needs a fsck, a fsck reports needing a full fsck then a error occurs. The data was good until it was unmounted. Today, the lv was resized from 263GB to 250GB and a fsadm was attempted to resize to 250GB but failed with Error 16 (busy), the apps were stopped and re-attemped with same error. What can be done?

[Jeff Schussele]

Hi Roland,

Full fsck syntax would be as follows

fsck -F vxfs -o full -y /dev/vg_name/rlv_name

Note that one uses the "raw" LV name.

Corruption be be of the extent that several passes are required - but not always. Run it once & try to mount if complains run it again.

HTH,
Jeff

[Roland Rebstock_1]

Its still erroring on the same bno and fails

[Jeff Schussele]

Well, it may be time to face the music & realize that you'll have to blow away the LV, recreate it & restore from backup.

If fsck cannot fix it then the only option is to use fsdb to repair it, BUT this should only be done if you're HIGHLY qualified as it's THE most destructive command this side of rm -rf.

You should engage the RC & log a SW call if you wish to attempt this. I can't emphasize this enough.

Good Luck,
Jeff

[Roland Rebstock_1]

can u help with fsdb? the man pages are not that helpfull

[Jeff Schussele]

Sorry - I wouldn't even attempt that on my own systems.

You really should log a call with the Response Center as I've never been very comfortable with fsdb and as stated it's *very* dangerous if you don't know 100% what you're doing.

Rgds,
Jeff

[Roland Rebstock_1]

Breaking out the backup tapes... TKS

[Bill Hassell]

The problem started when you resized the lvol downward...almost always guaranteed to destroy the filesystem! Now the possible good news: Increase the size of the lvol back to it's original value! When you resize an lvol (lvreduce or lvextend) you are changing the size if the disk area and NOT the filesystem. When you reduced the lvol, you sliced off part of the filesystem and fsck cannot fix this because the missing data simply does not exist. fsck is reporting errno 5 messages which means the requested track on disk is beyond the end of the lvol.

By resizing back to 263Gb, the missing data will appear and fsck should have no problems. HOWEVER, if you reduced the volume and then used lvextend in the same volume group, the missing extents may have been put into a different lvol and your 250Gb is worthless.

[Roland Rebstock_1]

should the fsadm to shrink the filesystem be run first?

[John Poff]

No, don't try to reduce the filesystem with fsadm. As Mr. Hassell has said, your best shot is to increase the size of the logical volume back to the original size and hope that it makes your filesystem happy again.

JP

[Roland Rebstock_1]

ive already blew it away and restoring from a hot backup. the next time I try to reduce a filesystem & volume, I should shrink the fs first then the volume?

[Bill Hassell]

No. The order should ALWAYS be:

1. Backup the filesystem
2. umount the filesystem
3. lvreduce the lvol
4. newfs the lvol (this erases the lvol)
5. restore the data.
6. mount the filesystem

Now, *if* this is a vxfs filesystem *AND* you have the optional Online JFS product + the optional Online JFS version 3.3, you can try using fsadm in place of steps 2-6, but reducing a filesystem is an inherently dangerous task to the health of the filesystem. A backup, then recreate and restore is always the safest.