On Tue, 2013-11-26 at 10:23 +-1100, NeilBrown wrote: +AD4- On Mon, 25 Nov 2013 09:59:39 -0500 Chuck Lever +ADw-chuck.lever+AEA-oracle.com+AD4- wrote: +AD4- +AD4- +AD4- Hi Neil- +AD4- +AD4- +AD4- +AD4- On Nov 24, 2013, at 11:59 PM, NeilBrown +ADw-neilb+AEA-suse.de+AD4- wrote: +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Trond, +AD4- +AD4- +AD4- I just noticed commit acdc53b2146c7ee67feb1f02f7bc3020126514b8 from 2010 +AD4- +AD4- +AD4- reverts the effect commit 28c494c5c8d425e15b7b82571e4df6d6bc34594d from Chunk +AD4- +AD4- +AD4- in 2007. +AD4- +AD4- +AD4- +AD4- I'm wondering if a subsequent commit changed filemap+AF8-write+AF8-and+AF8-wait(). +AD4- +AD4- I hadn't thought of that possibility. I've just had a look at the +AD4- differences between acdc53b2146c7ee6 and now and cannot find anything that +AD4- could be related. To clarify a little: my understanding is that the current 2-pass code in write+AF8-cache+AF8-pages() is supposed to prevent livelock. Instead of chasing PAGECACHE+AF8-TAG+AF8-DIRTY tags (which are constantly being set if an application is actively writing), we call tag+AF8-pages+AF8-for+AF8-writeback() once in order to convert the current set of PAGECACHE+AF8-TAG+AF8-DIRTY tags into PAGECACHE+AF8-TAG+AF8-TOWRITE tags, and then we have a second pass write those pages back (and wait for completion). IOW: the inode-+AD4-i+AF8-mutex should be unnecessary here... Now that said, we recently added in the call to nfs+AF8-inode+AF8-dio+AF8-wait(). If applications are using O+AF8-DIRECT, then +AF8-that+AF8- could livelock. There is nothing currently preventing the applications from continuing to bump the inode-+AD4-i+AF8-dio+AF8-count while we're waiting. Christoph has proposed some locking changes that should fix that problem. I'm still evaluating his patchset... Cheers Trond Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust+AEA-netapp.com www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
