Re: [PATCH] filemap_fdatasync & related changes

["Stephen C. Tweedie" <sct@redhat.com>]

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/