Well, I had a similar experience lately with the Adaptec AAC-2410SA RAID 5 array. Due to the CPU overheating the whole box was suddenly shot down by the CPU damage protection mechanism. While there is no battery backup on this particular RAID controller, the sudden poweroff caused some very localized inconsistency of one disk in the RAID. The configuration was 1x160 GB and 3x120GB, with the 160 GB being split into 120 GB part within the RAID 5 and a 40 GB part as a separate volume. The inconsistency happend in the 40 GB part of the 160 GB HDD (as reported by the Adaptec BIOS media check). In particular the problem was in the /dev/sda2 (with /dev/sda being the 40 GB Volume, /dev/sda1 being an NTFS Windows system, and /dev/sda2 being ext3 Linux system).
Now, what is interesting, is that Linux completely refused any possible access to every byte within /dev/sda, not even dd(1) reading from any position within /dev/sda, not even "fdisk /dev/sda", nothing. Everything ended up with lots of following messages:
sd 0:0:0:0: SCSI error: return code = 0x8000002
sda: Current: sense key: Hardware Error
Additional sense: Internal target failure
Info fld=0x0
end_request: I/O error, dev sda, sector <some sector number>
I've consulted this with Mark Salyzyn, because I thought it was a problem of the AACRAID driver. But I was told, that there is nothing that AACRAID can possibly do about it, and that it is a problem of the upper Linux layers (block device layer?) that are strictly fault intollerant, and thouth the problem was just an inconsistency of one particular localized region inside /dev/sda2, Linux was COMPLETELY UNABLE (!!!!!) to read a single byte from the ENTIRE VOLUME (/dev/sda)!
And now for the best part: From Windows, I was able to access the ENTIRE VOLUME without the slightest problem. Not only did Windows boot entirely from the /dev/sda1, but using Total Commander's ext3 plugin I was also able to access the ENTIRE /dev/sda2 and at least extract the most important data and configurations, before I did the complete low-level formatting of the drive, which fixed the inconsistency problem.
I call this "AN IRONY" to be forced to use Windows to extract information from Linux partition, wouldn't you? ;)
(Besides, even GRUB (using BIOS) accessed the /dev/sda without complications - as it was the bootable volume. Only Linux failed here a 100%. :()