lkml.org 
[lkml]   [2010]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: IO error semantics
    From
    On Mon, Jan 25, 2010 at 10:23 AM, Ric Wheeler <rwheeler@redhat.com> wrote:
    > On 01/18/2010 06:33 PM, Anton Altaparmakov wrote:
    >>
    >> Hi,
    >>
    >> On 18 Jan 2010, at 14:00, Nick Piggin wrote:
    >>
    >>>
    >>> For write errors, you could also do block re-allocation, which would be
    >>> fun.
    >>>
    >>
    >> Yes it would.  (-:
    >>
    >> FWIW, Windows does this with Microsoft's NTFS driver.  When a write fails
    >> due to a bad block, the block is marked as bad (recorded in the bad cluster
    >> list and marked as allocated in the in-use bitmap so no-one tries to
    >> allocate it), a new block is allocated, inode metadata is updated to reflect
    >> the change in the logical to physical block map of the file the block
    >> belongs to, and the write is then re-tried to its new location.
    >>
    >> I have never bothered implementing it in NTFS on Linux partially because
    >> there doesn't seem any obvious way to do it inside the file system.  I think
    >> the VFS and/or the block layer would have to offer help there in some way.
    >>  What I mean for example is that if ->writepage fails then the failure is
    >> only detected inside the asynchronous i/o completion handler at which point
    >> the page is not locked any more, it is marked as being under writeback, and
    >> we are in IRQ context (or something) and thus it is not easy to see how we
    >> can from there get to doing all the above needed actions that require memory
    >> allocations, disk i/o, etc...  I suppose a separate thread could do it where
    >> we just schedule the work to be done.  But problem with that is that that
    >> work later on might fail so we can't simply pretend the block was written
    >> successfully yet we do not want to report an error or the upper layers would
    >> pick it up even though we hopefully will correct it in due course...
    >>
    >> Best regards,
    >>
    >>        Anton
    >>
    >
    > For permanent write errors, I would expect any modern drive to do a sector
    > remapping internally. We should never need to track this kind of information
    > for any modern device that I know of (S-ATA, SAS, SSD's and raid arrays
    > should all handle this).
    >
    > Would not seem to be worth the complexity.
    >
    > Also keep in mind that retrying IO errors is not always a good thing -
    > devices retry failed IO multiple times internally. Adding additional retry
    > loops up the stack only makes our unavoidable IO error take much longer to
    > hit!
    >
    > Ric

    I thought write errors returned by modern drives (last 15 years) in
    general were caused by bad cables, controllers, power supplies, etc.

    When a media error is returned on write it indicated the spare sector
    area of the drive was full.

    Thus a media write error is a major error. I would think, if
    anything, we should turn the filesystem readonly upon a write media
    error. Not try to hide such a major problem.

    Greg
    --
    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/

    \
     
     \ /
      Last update: 2010-01-25 17:19    [W:3.227 / U:0.528 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site