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@xxxxxxx> 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. -- 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
