The read failure is catastrophic and not something that fsck can fix. fsck is a directory structure fixer, not a disk hardware fixer. If a fsck needs to read a block that is unreadable or worse, a block that is beyond the end of the disk, there is no possible solution with fsck. Did someone attempt to reduce the size of lvol4 recently? If so, that caused the problem and it is pretty serious. lvreduce has NOTHING to do with the filesystem.
A logical volume looks like a disk to the filesystem and if it is reduced, data towards the end of the lvol is inaccessible. The only solution is to extend the lvol back to it's original size (hopefully the free extents were used by another volume being created or extended).
The correct way to reduce an lvol with a filesystem is to backup the entire lvol, then un-mount the lvol, use lvreduce to remove some space, run newfs on the raw lvol to create a new filesystem and then restore the data. Now you can mount it. /var is particularly difficult because it is always in use so all of this must take place in single user mode. Note that Online JFS will almost always fail to reduce a volume without data loss. The exception is the Online JFS ver 3.3 version but the lvols must first be converted to ver 4 volumes. (in other words, you should assume that lvreduce will always destroy any filesystem on the lvol)
Bill Hassell, sysadmin
