(1.4.24) parted resize lost ext3 partition . . .suggestions?

[Gary Akers]

(1.4.24) parted resize lost ext3 partition  . . .suggestions?
I believe the partition is there, but my partition table says it is the new
smaller size and my superblock still says it is the old larger size.
Known error in procedure:   "didn't unmount the partition first"

After shrinking a (RH7.3)  mounted /usr partition with the command:
(parted ver. 1.4.24)

parted /dev/sda resize  5    1090.380   15000

(15000 was well within the empty range.)  That churned along for a while
and then reported an error indicating the kernel could not reread the 
partition
table and that I should reboot immediately with a rescue disk and reinstall
the boot loader [read section 4 of the parted user documentation.    . . 
.did that
[LILO].

On reboot the 7.3 box gets through LILO ok, but can't mount /usr
A manual fsck gives the error:

The filesystem size (according to the superblock is 5122719 blocks.  The 
physical size of the device is 3560397 blocks.  Either the superblock or 
the partition table is likely to be corrupt! abort<y>?
(aborted)

. . .then attempted to reverse the error in maintenance mode with   "parted 
/dev/sda resize  5    1090.380    21101"  reports success, but doesn't 
change line #5 below back to what it was.

[before]   parted  /dev/sda    print
minor    start                    end               type       filesystem 
flags
1               0.031                39.221         primary     FAT 

2             39.221            1066. 816       primary     ext3
3         1066.816           1090.349        primary     ext3            boot
4         1090.349         34710.754       extended
5         1090.380         21101.000       logical       ext3
6       21101.032         33094.841       logical       ext3
7       33094.872         34122.436                           linux-swap
8       34122.467         34640.156      logical       ext3
9       34640.187          34710.754     logical       ext3

[after]   parted  /dev/sda    print
same except for the expected line #5
5         1090.380         14998.183             logical       ext3

I've noted that the linux rescue environment doesn't complain about 
mounting the partition.
This happened in the middle of an upgrade at a time when my  backup won't 
be in sync.
After-the-fact  I have a  "cp -a"  backup with only about a dozen files or 
so showing IO
errors   If I get it back in time to get the project back on schedule, I'll 
verify everything to the
rpm signature database.

next day tried:

   e2fsck -f -n /dev/sda5

              pass 1:   checking inodes, blocks, & sizes error reading 
block 4097453
             (invalid argument) while reading indirect blocks of inode 
18290.
              Ignore error?  (no)
              Error while iterating over blocks in inode 18290: Invalid 
argument
              /usr:  /184724/2562240 files (0.2% non-contiguous), 
907103/512279
              blocks

and then tried     resize2fs -f -p /dev/sda5

              resize2fs:  Can't read an block bitmap while trying to rezize
                               /dev/sda5.  The file system is now 3560397
                               blocks long.

However,  the "change" to 3560397 doesn't stick as shown by subsequent
"parted /dev/sda print" and the fsck error indicating the size of the 
partition
doesn't match the size of the file system which I can't seem to get through
a successful fsck repair.
---end---
see ya Monday