Re: [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error
From: Dave Chinner <david@fromorbit.com>
Date: 2012-01-24 00:36:57
Also in:
linux-fsdevel, lkml
On Mon, Jan 23, 2012 at 04:47:09PM -0500, Ted Ts'o wrote:
quoted
The thing is, transient write errors tend to be isolated and go away when a retry occurs (think of IO timeouts when multipath failover occurs). When non-isolated IO or unrecoverable problems occur (e.g. no paths left to fail over onto), critical other metadata reads and writes will fail and shut down the filesystem, thereby terminating the "try forever" background writeback loop those delayed write buffers may be in. So the truth is that "trying forever" on write errors can handle a whole class of write IO errors very effectively....So how does XFS decide whether a write should fail and shutdown the file system, or just "try forever"?
The IO dispatcher decides that. If the dispatcher has handed the IO off to the delayed write queue, then failed writes will be tried again. If the caller is catching the IO completion (e.g. sync writes) or attaching a completion callback (journal IO), then the completion context will handle the error appropriately. Journal IO errors tend to shutdown the filesystem on the first error, other contexts may handle the error, retry or shutdown the filesystem depending on their current state when the error occurs. Reads are even more complex, because ithe dispatch context can be within a transaction and the correct error handling is then dependent on the current state of the transaction.... Cheers, Dave. -- Dave Chinner david@fromorbit.com