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).