On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@xxxxxxxxx> wrote: >> There's nothing in libata which will cause the operation to eventually >> return success if the drive keeps failing it (at least there definitely >> should not be and I very much doubt there is). My guess is that somehow what >> you think should be happening is not what the drive is actually doing (maybe >> one of the retries you're seeing is actually succeeding in writing to the >> disk, or at least the drive reports it was). >> >> You haven't posted any of the actual kernel output you're seeing, so it's >> difficult to say exactly what's going on. However, attempting to scan for >> disk errors using writes seems like a flawed strategy. As several people >> have mentioned, drives can't necessarily detect errors on a write. >> > > The scenario involves lots of bad drives with the known bad sectors > locations. Take MHDD for example, it sends an ATA write command to one > of the bad sectors, the drive returns failure / timeout, it tries > again, the drive still says failure / timeout, program comes out and > says failure. If we are not checking the errors during write process, > and continue to reallocate the sector or retry the write again, what > happens after all the available sectors are remapped? I still could > not visualise it for some reasons. > > Consider this scenario: > My write program says write passed. But when I used another > verification program (replica of the erasure program but does only > read / verify) it is unable to read the data and returns failure. No > other program (for example a Windows based hex editor or DOS based > disk editor) is able to read the information from that particular > sector. So, obviously the data written by linux is corrupted and > cannot be read back by any other means. And the program which wrote > the data is unaware of the error that has happened at the lower level. > But the error log clearly has the issue caught but is trying to handle > differently. > > I've attached a part of sample dmesg log which was logged during the > grinding of bad sector operation and eventually the write passed. [ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 [ 7671.006936] ata1.00: BMDMA stat 0x25 [ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in [ 7671.006945] res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error) [ 7671.006949] ata1.00: status: { DRDY ERR } [ 7671.006951] ata1.00: error: { UNC } [ 7671.028606] ata1.00: configured for UDMA/100 [ 7671.028617] ata1: EH complete Command C8 is a read that's failing. It looks like almost all of the failures in that log are from failed reads, I don't see any failed writes. From what I can see it sounds like the drive is apparently writing successfully but is unable to read the data back (the reads being due to read-modify-write operations being done or for some other reason). -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html