From: bfields@fieldses.org (J. Bruce Fields)
To: Goran <sendmailtogoran@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: unstable nfs connection
Date: Mon, 14 May 2018 17:18:22 -0400 [thread overview]
Message-ID: <20180514211822.GD29264@fieldses.org> (raw)
In-Reply-To: <CABS5c+GR6xJwV6im=N36Qmax-P6ZWrJYwDDVdekF3LWQ0tToXw@mail.gmail.com>
On Fri, May 11, 2018 at 12:21:59PM +0200, Goran wrote:
> I have an issue with nfs which I'm using the first time.
>
> I have a server running arch linux. Further the server is running
> several container, each container itself is running arch linux too.
> One container is running nfsd.
>
> The nfs-container is connected via a virtual bridge. The bridge is
> hosted by the server. One physical device is connected to that bridge.
> A physical switch is connected to that physical device. The client is
> connected to the physical switch.
>
> To keep it simpler:
> client -- clients NIC -- physical switch -- server NIC -- server
> bridge -- container NIC -- container
>
> At first sight, everything works well, I can boot diskless/readonly
> from NFS. I use dracut for that. I can log into the client and start
> working.
>
> If the client is just doing nothing I get after some time (e.g. 5 minutes)
>
> nfs: server 172.17.0.5 not responding. still trying
>
> or
>
> nfs: server 172.17.0.5 not responding.timed out
>
> If 10 clients starts at same time, the above error comes immediatly.
>
> I took a look like at the containers nic
>
> 23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether 42:3b:82:03:c0:7d brd ff:ff:ff:ff:ff:ff link-netnsid 0
> RX: bytes packets errors dropped overrun mcast
> 44184595 388170 0 205 0 0
> TX: bytes packets errors dropped carrier collsns
> 902023963 112922 0 0 0 0
>
> but this seems not too much dropped packages for me. I'm more a C++
> guy, not as much an Linux admin. So I'm asking how can I debug this
> nfs-connection to make it stable?
I don't know. My first impulse would be to blame some problem at the
networking level rather than NFS itself. (Are those dropped packets
normal? Can you reproduce problems with any protocol other than NFS?)
What are you using to set up the containers? What does the server
bridge look like? I wonder if there's some misconfiguration of the
bridge or of the server's virtual NIC, or an odd firewalling issue.
It *might* help to try watching the traffic over various interfaces with
wireshark.
--b.
prev parent reply other threads:[~2018-05-14 21:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 10:21 unstable nfs connection Goran
2018-05-14 21:18 ` J. Bruce Fields [this message]
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=20180514211822.GD29264@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=sendmailtogoran@gmail.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.