I'm not following all of this, but here are a few comments. Are you sure that /usr is mounted? Are you sure that you don't know the device name? It's not easy to find out that a file system is mounted without also obtaining the device name. For example, with the "df" command, the device name is the first field. You can just examine /etc/fstab to get the device name. But you should not actually need the device name. Modern versions of fsck will look it up in /etc/fstab. So simply:
fsck /usr
really should work.

Ideally you should find some way to umount /usr or arrange that it was never mounted prior to fsck. A boot cd (can linux really boot from a diskette?) would be a good option. You're right that running fsck on a mounted filesystem is very dangerous. This is because some of the data from that filesystem is sitting in buffer cache. When this cache is written out, it will intermix with the data written by fsck and scramble the filesystem. So you need to do the following sequence of commands:
sync
<wait 10 seconds or so>
fsck /usr
reboot -n

The first sync will flush out any changed data in / or any other mounted filesystems. You need to wait until the disk writes complete. Then run fsck.
Then immediately reboot without syncing. Also during this entire procedure, almost nothing else must be happening. It is relatively safe in single user mode. This is not completely safe, but your system is not usuable anyway, so it is what I would try. There is a risk of damaging other mounted filesystems. The first sync together with minimizing activity should mitigate this danger. If you decide to try it, please post back and let us know how it works.

However, even if this does work, you may not be home free. fsck may not be able to repair your disk. "attempt to read blocks from filesystem resulted in short read" make me think that your disk may be bad in a hardware sense. fsck cannot repair broken hardware.

Whether or not fsck seems to work, you must immediately do the "reboot -n". Good luck.