On Fri, 12 Dec 2008 00:43:35 +0100 Nick Piggin <npiggin@xxxxxxx> wrote: > On Thu, Dec 11, 2008 at 03:14:07PM -0800, Andrew Morton wrote: > > On Thu, 11 Dec 2008 23:45:14 +0100 > > Nick Piggin <npiggin@xxxxxxx> wrote: > > > > > > > For simplicity, I have removed the "don't wait for writeout if we hit -EIO" > > > > > logic from a couple of places. I don't know if this is really worth the added > > > > > complexity (EIO will still get reported, but it will just take a bit longer; > > > > > an app can't rely in specific behaviour or timeliness here). > > > > > > > > This is ungood. The device layer likes to twiddle thumbs for 30 > > > > seconds or more when it hits an IO error. We went and made that 30,000 > > > > or more.. > > > > > > It isn't really a good solution anyway, > > > > what isn't a good solution to what? > > To the problem of long waits on IO errors. > > > > > 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" ;) Metadata can get evicted early because it's in lowmem. We don't instantiate the blocks at fault time for MAP_SHARED writes (do we? we were thinking of doing so) > 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. -- 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
