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

[Nick Piggin <npiggin@suse.de>]

On Thu, Dec 11, 2008 at 02:45:02PM -0800, Andrew Morton wrote:
> On Thu, 11 Dec 2008 23:32:13 +0100
> Nick Piggin <npiggin@suse.de> wrote:
> 
> > The livelock behaviour? (or the error propagation).
> > 
> > I first heard about it from Mikulas, where some dm tool locks up because
> > it does direct IO on the block device of mounted filesystem (or something
> > like that).
> 
> Does it actually lock up?  Or does it just take a loooong time?

Just takes a looong time.

 
> Presumably it can be worked around in userspace.

Depends. It's very easy to get stuck behind a dirtier, but OTOH,
do many applications do such a thing? I simply don't know.

Livelock due to sys_sync would be easier (because then you have
lots of other apps all doing their own thing which you aren't
in control of, but I don't want to optimise for apps calling sys_sync,
and the sync command basically should only be for testing).

Point is, I don't know :) Probably not a bad idea to leave it out
and then think about it again if anybody cares.
 

> > That case is actually mostly solved by my first ptach in the
> > series. 
> 
> mm-direct-io-starvation-improvement.patch?   I guess that would help
> a lot.  I can't imagine why we didn't do that years ago???
> 
> Can we please determine whether that optimisation was sufficient
> for Mikulas's example?

Yes, that patch. I was able to reproduce the problem here, and that
did solve it for me, but yes confirming it with the actual dm tools
would be nice.


> > > Why fix it?
> > 
> > Good question. My earlier patches already in your tree removed some starvation
> > avoidance code because they were breaking data integrity semantics. So in
> > theory, your tree today is more susceptible to this sync/fsync starvation
> > than mainline. I care most about the correctness, and it would be great if
> > nobody cares about this starvation problem so we don't need the extra
> > complexity.
> 
> Yes, it does add quite a bit of complexity and more code.  It'd be good
> if we could find some way of avoiding merging it.

Well, don't merge it yet then.

Oh, but we still have this fsync error may not get propagated problem...
I guess that should be solved in a broken out patch anyway.