On Wed, 31 Jul 2013 10:03:28 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Fri, Jul 26, 2013 at 10:25:10PM +0000, Larry Keegan wrote: > > As far as NFS client arrangements are concerned, both of the NFS > > server machines also function as NFS clients, so /home/larry works > > on them in the same way as it does on any other NFS client on the > > network. It is just that the NFS servers also run my postfix MTAs. > > It's unrelated to your ESTALE problem, but note that a setup like this > may be prone to deadlock. (The client may need to write to the server > to free up memory. The server may need memory to service the write. > If the server and client are on the same machine, this can deadlock.) > > --b. > Dear Bruce, Perhaps you can clear something up for me. If I understand you correctly, the following commands might lead to deadlock: nfsserver# mount localhost:/filesystem /mnt nfsserver# memory-eater & [1] 1234 nfsserver# echo tip it over the edge > /mnt/file but that it won't deadlock if there is memory to spare. The reason I ask is I'd always assumed that any 'spare' memory in an active Linux system would end up being consumed by the disc cache, and that the cached pages are discarded or copied to disc when other parts of the system want memory (or sooner), assuming there is memory available to do that. What I'm asking is whether this deadlock scenario is 'prone' to occur whenever there are insufficient reclaimable pages free or whether this can occur before that point? Can this deadlock occur even if the cache is large enough to ensure that most of what it contains has been written to disc already? IOW, ignoring the other parts of the O/S, if a programme writes 100MB/sec maximum to an NFS mounted directory on the same machine, and the NFS server commits its data to disc within 10 seconds say, would 4GB of RAM provide enough headroom to make this deadlock unlikely? Yours, Larry. -- 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
