On Thu, Dec 11, 2008 at 04:39:43PM -0800, Andrew Morton wrote: > On Fri, 12 Dec 2008 00:43:35 +0100 Nick Piggin <npiggin@xxxxxxx> wrote: > > > > > because I think it's much > > > > less likely for writepage to return -EIO directly. Usually they > > > > would come back via data IO completion asynchronously. > > > > > > umm, maybe. If all the file metadata is in pagecache. Often it is not. > > > > I'd say, often it *is* because the buffer layer allocates/maps/reserves > > blocks for the page when it gets dirtied. > > Depends on the value of "often" ;) Very true. > Metadata can get evicted early because it's in lowmem. Yes, although highmem isn't "often" these days :) And for non-highmem, you would expect the page to be written back before buffer heads are reclaimed. > We don't instantiate the blocks at fault time for MAP_SHARED writes > (do we? we were thinking of doing so) No. Well, some filesystems do I think. But not many. There were patches for ext*. But I think MAP_SHARED writes aren't terribly common either. > > Of course these checks will catch some cases for some filesystems, but > > they're not a good general solution to the problem of EIO errors taking > > a long time, IMO, because there are other ways it can happen. > > Well it's one of those things where a 90% solution is 90% better than no > solution. Or maybe a 20% solution is better than no solution too -- it's not a lot of code as is. It would have got a little more complex after my FSYNC tag patch. But we haven't even decided if that's a good idea to begin with, so let's not get ahead of ourselves :) How can this be solved nicely? Have an error rate threshold in the block device code, after which the queue shuts down and starts synchronously rejecting requests? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
