Any help would be much appreciated.

I rebooted my server the other night and on reboot received the following error:

e2fsck: Invalid argument while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Now /dev/md1 is a large RAID5 filesystem (3Tb)

I dont remember setting a block size parameter when I created the EXT3 file system on it.

Having run

mke2fs -n /dev/md1 976759808
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
61054976 inodes, 244189952 blocks
12209497 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

I have tried innumerable variations of

e2fsck -b 32768 -B 4096 /dev/md1

(took a while to find that the version of e2fsck I am running has a bug that needs an explicit blocksize set)

with the blocks indicated by the mke2fs command above but all failed to restore the superblock. All came back with the same error as above.

Doing DMESG | tail gives :

EXT3-fs: unable to read superblock

I have been reviewing the internet for solutions but still cant mount the drive.

Also tried to reset the superblocks with :

mke2fs -b 4096 -S /dev/md1 976759808
mke2fs 1.40.8 (13-Mar-2008)
mke2fs: Filesystem larger than apparent device size.
Proceed anyway? (y,n) y
Warning: 256-byte inodes not usable on older systems
Warning: could not erase sector 2: Invalid argument
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
244195328 inodes, 976759808 blocks
48837990 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
29809 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544

Writing superblocks and filesystem accounting information:
Warning, had trouble writing out superblocks.done

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Note the message about problems writing out the superblocks.

After this I still get the error when trying to mount the filesystem.

mount: wrong fs type, bad option, bad superblock on /dev/md1,
missing codepage or helper program, or other error
(could this be the IDE device where you in fact use
ide-scsi so that sr0 or sda or so is needed?)
In some cases useful info is found in syslog - try
dmesg | tail or so

Any suggestions will be greatly tried

Thanks for your time

Are you sure the RAID is functioning correctly?
It sounds like you've focused on the superblock error without investigating why it can't find one.
Check your RAID logs...

Thanks for your response ......

If only you had logged in a bit earlier!

I rebooted my system today and the sameproblem had recurred - I had previously decided to move on with my life, reformatted the array and restored what I could from backups (lets just say that I've obvously cleared out a lot of dead wood - I now have heaps of free space on the array).

Taking your advice I tried mdadm --detail /dev/md1 and got a 'array does not appear to be active' message. So did mdadm --auto-detect and after that the --detail worked and the array would mount.

I hope that this is the problem though I had assembled the drive previously but perhaps by that stage it was too late and I might have already corrupted the filesystem

Either way it's up (again) now thanks for your hint. Not 100% sure this was the problem last time but certainly looks like it.