linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Keegan <lk@pfw.demon.co.uk>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@redhat.com>, <linux-nfs@vger.kernel.org>
Subject: Re: nfs client: Now you see it, now you don't (aka spurious ESTALE errors)
Date: Wed, 31 Jul 2013 19:50:17 +0000	[thread overview]
Message-ID: <20130731195017.334bb05c@cs3.al.itld> (raw)
In-Reply-To: <20130731140328.GA28266@fieldses.org>

On Wed, 31 Jul 2013 10:03:28 -0400
"J. Bruce Fields" <bfields@fieldses.org> 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.

  reply	other threads:[~2013-07-31 19:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 13:45 nfs client: Now you see it, now you don't Larry Keegan
2013-07-25 14:11 ` nfs client: Now you see it, now you don't (aka spurious ESTALE errors) Jeff Layton
2013-07-25 14:24   ` Myklebust, Trond
2013-07-25 14:33     ` Jeff Layton
2013-07-25 14:41       ` Myklebust, Trond
2013-07-25 17:05   ` Larry Keegan
2013-07-25 18:18     ` Jeff Layton
2013-07-26 12:41       ` Larry Keegan
2013-07-26 13:12         ` Jeff Layton
2013-07-26 15:02           ` J. Bruce Fields
2013-07-26 22:25             ` Larry Keegan
2013-07-31 14:03               ` J. Bruce Fields
2013-07-31 19:50                 ` Larry Keegan [this message]
2013-07-31 20:35                   ` J. Bruce Fields
2013-07-26 16:10           ` Larry Keegan
2013-07-26 14:59     ` J. Bruce Fields
2013-07-26 23:21       ` Larry Keegan
2013-08-06 11:02         ` Larry Keegan
2013-08-06 11:14           ` Jeff Layton
2013-08-06 13:34             ` J. Bruce Fields
2013-08-06 15:38               ` Larry Keegan
2013-08-19 21:16       ` Bruce Guenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130731195017.334bb05c@cs3.al.itld \
    --to=lk@pfw.demon.co.uk \
    --cc=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).