public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Michael O'Donnell" <modonnell@wsi.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFS stops responding
Date: Thu, 15 Apr 2010 14:04:31 -0400	[thread overview]
Message-ID: <20100415180431.GA13717@fieldses.org> (raw)
In-Reply-To: <4BC62E38.3010704@wsi.com>

On Wed, Apr 14, 2010 at 05:06:00PM -0400, Michael O'Donnell wrote:
> When I display the client traffic log file with Wireshark, it (apparently)
> confirms that the client did indeed wait a while and then (apparently)
> retransmitted the NFS request.  The weird thing is that Wireshark analysis
> of corresponding traffic on the server shows the first request coming in
> and being replied to immediately, then we later see the retransmitted
> request arrive and it, too, is promptly processed and the response goes
> out immediately.  So, if I'm reading these tea leaves properly it's as if
> that client lost the ability to recognize the reply to that request.  [?!]
>
> But, then, how could it be that all 3 machines seem to get into this state
> at more or less the same time?  and why would unmounting and remounting
> all NFS filesystems then "fix" it?   Aaaiiieeee!!!

I don't know, I haven't seen that.

> I know of no reasons in principle why two machines can't simultaneously
> act as NFS clients and NFS servers - are there any?  AFAIK the two
> subsystems are separate and have no direct dependencies or interactions;
> does anybody know otherwise?

Well, they can compete for common resources (like memory), and in that
case there are at least theoretical deadlocks.  (A's server can't
proceed until gets some memory, but first it needs A's client to flush
some dirty pages, which depends on server B processing some request,...
etc.)

I don't know how to actually reproduce such a deadlock, but I wouldn't
recommend depending on its absence, either.

--b.

  reply	other threads:[~2010-04-15 18:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14 21:06 NFS stops responding Michael O'Donnell
2010-04-15 18:04 ` J. Bruce Fields [this message]
2010-04-17  0:17 ` Dennis Nezic
     [not found]   ` <20100416201700.215b0bea.dennisn-YN8wfZw00oOZ9vWoFJJngh2eb7JE58TQ@public.gmane.org>
2010-04-19 14:34     ` Michael O'Donnell
     [not found]       ` <4BCC69E4.70405-kx56TfycDUc@public.gmane.org>
2010-04-22 15:19         ` Dennis Nezic
2010-04-28 15:51           ` Dennis Nezic
  -- strict thread matches above, loose matches on Subject: below --
2004-09-30 13:39 Douglas Furlong
2004-09-30 16:06 ` Jason Holmes
2004-09-30 19:10   ` Jason Holmes
2004-10-01 15:40     ` Jason Holmes
2004-10-07 10:56       ` Douglas Furlong
2004-10-13 15:07         ` Jason Holmes

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=20100415180431.GA13717@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=modonnell@wsi.com \
    /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