linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Hawley <bhawley@luminex.com>
To: linux-nfs@vger.kernel.org
Subject: i/o still hangs when nfs server unavailable even with soft mount option
Date: Mon, 03 Jun 2013 19:41:19 -0700	[thread overview]
Message-ID: <51AD53CF.3080604@luminex.com> (raw)


I've noticed that even with 'soft' mount specified as an option, i/o 
will continue to cache (after a server has gone away - or the clients 
links to it), at which point it hangs, instead of returning an i/o error 
as I would expect based on the man pages.

For our environment, speed is more important than reliability as when we 
lose access to one of the nfs mounts, we cease writing new data to it 
and journal it on the remaining available mounts.

Based on the descriptions in the various manuals, I would have thought 
'soft' mount would have given us an i/o error on any write (or read) 
which failed.

This however, isn't the case, unless 'sync' is also set.

I believe the reason for this has to do with somewhere in the cache 
handling.   Even when the mount is set to 'soft', without 'sync' the 
writes go to the cache, until the cache is full and the client wants to 
perform the actual write to the server.   It is at this time, that it 
stays stuck and never returns, irregardless of the timeo and retrans 
options, until the server (or links to it) have been restored.

If 'sync' is on, the i/o error occurs as expected.    However, 'sync' 
has a significant performance penalty, even if the server exports the 
filesystem as 'async'.

I wasn't able to find anything in the archives about this, but did find 
one other reference in 2010 to this same issue, but without any reply or 
comment about a solution.

Does anyone know how I might get this working, or could point me to the 
correct location in the kernel fs sources to effect my own change to the 
kernel handling?

Thanks,

-- Brian


                 reply	other threads:[~2013-06-04  3:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=51AD53CF.3080604@luminex.com \
    --to=bhawley@luminex.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).