From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: NFS over localhost?
Date: Mon, 05 Dec 2005 08:13:39 -0500
Message-ID: <1133788419.8027.24.camel@lade.trondhjem.org>
References: <Pine.LNX.4.44.0512050921200.18221-100000@lothlorien.local>
Mime-Version: 1.0
Content-Type: text/plain
Cc: nfs@lists.sourceforge.net
To: Helge Bahmann <hcb@chaoticmind.net>
In-Reply-To: <Pine.LNX.4.44.0512050921200.18221-100000@lothlorien.local>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

On Mon, 2005-12-05 at 09:37 +0100, Helge Bahmann wrote:

> Symptoms: Under heavy write load ("dd if=/dev/zero of=/import/x") both NFS
> client and NFS server deadlock reproducibly, various kernels 2.6.8 -
> 2.6.15-rc4 affected, both SMP and non-SMP. All accesses to "/import" hang
> indefinitely, sometimes also the mount-point "/export" becomes unusable;
> both reiserfs and ext3 as back-end filesystems are affected. This
> situation happens as the "free" memory (as reported by vmstat)
> approaches zero, so it may possibly be an out-of-memory-thing.
> 
> Question(s): Is this kind of deadlock "supposed" to happen? I mean, there
> is no purpose in using NFS in this kind of way (except for configuration
> testing), so I can imagine no one bothers to clean up the interaction
> between NFS client and server in this scenario. However I am slightly
> concerned that a similiar scenario might be possible with our "real" NFS
> server, as it can receive data faster over the network than it can write
> out to the disks. Is this possible?

No, that kind of deadlock is not _supposed_ to happen, but it is very
hard to avoid. Doing loopback mounts will always confuse the VM.
The problem is that the client side can only deal with memory pressure
by writing out pages and then sending them to the server. Since the
server in this case is itself, that therefore actually increases the
memory pressure.
A setup in which client and server are not the same should be a lot more
stable, but there are scenarios where deadlocks can occur there too.

Note that 2.6.15-rc5 includes a fix that should help with one known
client-side out-of-memory scenario, but since that is more related to
shared mmap(), I doubt it will help you here.

Cheers,
  Trond


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs