Re: [patch 6/6] mm: fsync livelock avoidance

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 12 Dec 2008 00:43:35 +0100 Nick Piggin <npiggin@suse.de> 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@suse.de> 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.