From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
To: Jim Rees <rees@umich.edu>
Cc: linux-nfs@vger.kernel.org, akpm@linux-foundation.org,
mingo@redhat.com, neilb@suse.de, stuart.menefy@st.com,
chuck.lever@oracle.com, bharrosh@panasas.com
Subject: Re: [PATCH 3.3.0-rc1 1/2] do_mounts: Change the nfs-mount retry min max delays.
Date: Thu, 26 Jan 2012 15:06:57 +0000 [thread overview]
Message-ID: <4F216C11.9070906@st.com> (raw)
In-Reply-To: <20120126145520.GA10112@umich.edu>
Jim Rees wrote:
> You may want to read the mailing list thread from the earlier patch. I
> don't remember the details but lowering the panic timeout from 110 to 41
> seconds may re-introduce the problem that patch was trying to solve. You
> could increase the retry count to compensate.
>
>From commit 43717c7d, "NFS: Retry mounting NFSROOT" log.
Original problems looks exactly same as the one I encountered.
First operation was an rpcbind request to determine which port the NFS
server was listening on timeout in 2-3 seconds, by this time Switch was
ready. which was then followed by default nfs port 2049 selection at
this time the nfs mount was successful.
In my case the PHY became ready just before the second attempt, same as
LAN switch in the original issue.
I think most of the cases fall in this category.
So there was no delay before this patch except the timeout from rpcbind
was sufficient delay to get the Switch/PHY(in my case) in working state.
I think introduction of timeout actually was not necessary for the
second attempt.
If user want to have more delay than 41 secs, he will be able to
increase the retry count from my mount-retry kernel param patch.
Thanks,
srini
next prev parent reply other threads:[~2012-01-26 15:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 14:42 [PATCH 3.3.0-rc1 1/2] do_mounts: Change the nfs-mount retry min max delays Srinivas KANDAGATLA
2012-01-26 14:55 ` Jim Rees
2012-01-26 15:06 ` Srinivas KANDAGATLA [this message]
2012-01-26 15:35 ` Chuck Lever
2012-01-27 8:10 ` Srinivas KANDAGATLA
2012-01-27 12:34 ` Jim Rees
2012-01-30 7:46 ` Srinivas KANDAGATLA
2012-02-03 10:11 ` Srinivas KANDAGATLA
2012-02-03 13:16 ` Jim Rees
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=4F216C11.9070906@st.com \
--to=srinivas.kandagatla@st.com \
--cc=akpm@linux-foundation.org \
--cc=bharrosh@panasas.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=neilb@suse.de \
--cc=rees@umich.edu \
--cc=stuart.menefy@st.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 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.