All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin ESTRABAUD <be@mpstor.com>
To: linux-nfs@vger.kernel.org
Subject: NFS auto-reconnect tuning.
Date: Wed, 24 Sep 2014 16:39:55 +0100	[thread overview]
Message-ID: <5422E5CB.6000402@mpstor.com> (raw)

Hi!

I've got a scenario where I'm connected to a NFS share on a client, have 
a file descriptor open as read only (could also be write) on a file from 
that share, and I'm suddenly changing the IP address of that client.

Obviously, the NFS share will hang, so if I now try to read the file 
descriptor I've got open (here in Python), the "read" call will also hang.

However, the driver seems to attempt to do something (maybe 
save/determine whether the existing connection can be saved) and then, 
after about 20 minutes the driver transparently reconnects to the NFS 
share (which is what I wanted anyways) and the "read" call instantiated 
earlier simply finishes (I don't even have to re-open the file again or 
even call "read" again).

The dmesg prints I get are as follow:

[ 4424.500380] nfs: server 10.0.2.17 not responding, still trying <-- 
changed IP address and started reading the file.
[ 4451.560467] nfs: server 10.0.2.17 OK <--- The NFS share was 
reconnected, the "read" call completes successfully.

I would like to know if there was any way to tune this behaviour, 
telling the NFS driver to reconnect if a share is unavailable after say 
10 seconds.

I tried the following options without any success:

retry=0; hard/soft; timeo=3; retrans=1; bg/fg

I am running on a custom distro (homemade embedded distro, not based on 
anything in particular) running stock kernel 3.10.18 compiled for i686.

Would anyone know what I could do to force NFS into reconnecting a 
seemingly "dead" session sooner?

Thanks in advance for your help.

Regards,

Ben - MPSTOR.

             reply	other threads:[~2014-09-24 15:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 15:39 Benjamin ESTRABAUD [this message]
2014-09-25  1:44 ` NFS auto-reconnect tuning NeilBrown
2014-09-25  9:46   ` Benjamin ESTRABAUD
2014-09-28 23:28     ` NeilBrown
2014-09-29 10:06       ` Benjamin ESTRABAUD
2014-09-29 21:34         ` NeilBrown

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=5422E5CB.6000402@mpstor.com \
    --to=be@mpstor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.