My point was, did you run xfs_{check|repair} on /dev/hdx or /dev/mapper/LogicalVolumeName?

If you did the former, and ran the "repair" function, you may well have completely "trashed" your logical volume(s). The symptom you mention (re Superblocks) is typically reported when the check (or repair) programs are run against an invalid (e.g., LVM) disk partition.

I have only issued xfs_repair on the logical volume, not the drives themselves (obviously after unmounted the lvm). I'm going to install SuSE 10.1 (latest release) tonight and see if it makes any difference. Thanks for trying to help PTrenholme!

Tried installing newest SuSE (10.1), no success, same error.

Also tried running xfs_check and xfs_repair on the logical volume (thru /dev/mapper/logicalvolume), this also freezes the system instantly.

My next step would be to somehow test my disks individually, but I am clueless on how to proceed with this.
My disks are varying from 120~300 GB in size. Would it be possible to make an identical copy of any of the drives using a 300 GB disk (using Ghost or similar application) and replacing the disks one by one? Or would this operation require the disk to be identical with its original?

EDIT:
I guess before I do something like that I _really_ need to make sure the fs is not scrambled, cause then it would lead to the exact same thing.

I am now able to copy the data from the LVM in pieces, up until the point where my system freezes. But if I reboot the system and copy the same files, it works. So for me, the worst part is over. However, I was never able to find a solution to this problem, nor was I able to determine exactly what the problem was, even after ruling out several factors. The disks seem to be intact. Please see above replies for my previous actions in order to determine the cause of error.

Thanks to the people who tried helping me out, support like yours is more valuable than anything when you don't have anywhere to turn. Thanks guys.