Messages in this thread | | | Date | Thu, 4 Jan 2001 18:46:04 +0000 | From | "Stephen C. Tweedie" <> | Subject | Re: [PATCH] filemap_fdatasync & related changes |
| |
hi,
On Wed, Jan 03, 2001 at 10:28:05AM -0800, Linus Torvalds wrote: > > On Wed, 3 Jan 2001, Chris Mason wrote: > > > > Just noticed the filemap_fdatasync code doesn't check the return value from > > writepage. Linus, would you take a patch that redirtied the page, puts it > > back onto the dirty list (at the tail), and unlocks the page when writepage > > returns 1? > > I don't see how that would help. It's just asking for endless loops.
Ultimately our whole IO-error handling for writes is fundamentally broken right now, at least at the buffer_head level. We just don't have any mechanism in the buffer_head for distinguishing between write errors and read errors. If you get a write error, the next reader who happens upon that buffer will see an invalid buffer and will try to reread from disk, discarding the newer data from cache that we had problems writing.
It's less of a problem with the page cache in 2.4 because such a write error doesn't set the page to being not-uptodate, but the problem is still there. If we're going to start trying to be rigorous about propagating driver write failure notification back up to user space (eg. for O_SYNC), then ideally we need to do it in conjunction with a rethink of the end_request() code.
The only reason I've come up against this particular problem recently is that it impacts journaling filesystems. It can lead to buffers in memory suddenly appearing non-uptodate after a write, causing subsequent reads to submit disk IOs on a buffer which the journaling code expects to be unlocked.
--Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |