Messages in this thread | | | Subject | RE: FYI: RAID5 unusably unstable through 2.6.14 | Date | Fri, 3 Feb 2006 12:00:02 -0500 | From | "Salyzyn, Mark" <> |
| |
Martin Drab [mailto:drab@kepler.fjfi.cvut.cz] sez: > That may very well be true. I do not know what the Adaptec > BIOS does under the "Low-Level Format" option. Maybe someone from Adaptec > would know that.
The drive is low level formatted. This resolved the problem you were having.
> No, I don't think this was the case of a physically bad > sectors. I think it was just an inconsistency of the RAID controllers metadata (or > something simillar) related to that particular array.
It was a case of a set of physically bad sectors in a non-redundant formation resulting in a non-recoverable situation, from what I could tell. Read failures do not take the array offline, write failures do. Instead the adapter responds with a hardware failure to the read responses. Writing the data would have re-assigned the bad blocks. (RAID controllers do reassign media bad blocks automatically, but sets them as inconsistent under some scenarios, requiring a write to mark them consistent again. This is no different to how single drive media reacts to faulty or corruption issues).
The bad sectors were localized only affecting the Linux partition, the accesses were to directory or superblock nodes if memory serves. Another system partition was unaffected because the errors were not localized to it's area.
Besides low level formatting, there is not much anyone can do about this issue except ask for a less catastrophic response from the Linux File system drivers. I make no offer or suggestion regarding the changes that would be necessary to support the system limping along when file system data has been corrupted; UNIX policy in general is to walk away as quickly as possible and do the least continuing damage.
Except this question: If a superblock can not be read in, what about the backup copies? Could an fsck play games with backup copies to result in a write to close inconsistencies?
-- Mark Salyzyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |