[lkml]   [2010]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux kernel - Libata bad block error handling to user mode program
    On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <> 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

     \ /
      Last update: 2010-03-05 03:19    [W:0.038 / U:6.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site