New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NFS mount to WinNFSd stops working after about 15-30 minutes #68

Open
pietervogelaar opened this Issue Sep 10, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@pietervogelaar

pietervogelaar commented Sep 10, 2018

I'm running Windows 10 and WinNFSd 2.4.0.

I start WinNFSd in the foreground with:
WinNFSd.exe -pathFile "C:\Users\myname\etc\nfs-pathfile.txt"

The content of nfs-pathfile.txt:
C:\Users\myname\minikube\sources

From my Minikube VM I create an NFS mount with:
sudo mkdir -p /host-sources && sudo mount -t nfs -o nfsvers=3,tcp 192.168.99.1:/C/Users/myname/minikube/sources /host-sources

At this point, it works great! I can list, read and write files. The WinNFSd program logs all kind of file access very fast.

However after about 15-30 minutes, if I do a ls -sal /host-sources the client just keeps waiting / hanging. When this happens, no information is added to the log. Also with retries of the command, it still hangs and no information is added to the WinNFSd log. So I have no clue what is going on.

I disabled all sleep / energy settings, also the disks are never turned off. But I still get this problem. Do you have any idea what goes wrong? Or what options there are left to try?

Do others have WinNFSd running fine for at least a couple of days?

@pietervogelaar

This comment has been minimized.

Show comment
Hide comment
@pietervogelaar

pietervogelaar Sep 11, 2018

It keeps working if I change the protocol from tcp to udp. Symantec security is running, maybe that's the problem.

pietervogelaar commented Sep 11, 2018

It keeps working if I change the protocol from tcp to udp. Symantec security is running, maybe that's the problem.

@pietervogelaar

This comment has been minimized.

Show comment
Hide comment
@pietervogelaar

pietervogelaar Sep 11, 2018

I completely removed Symantec, and made an exclusion of the C:\Users\myname\minikube path in Windows defender, but I still experience the same problem if I use the tcp protocol.

pietervogelaar commented Sep 11, 2018

I completely removed Symantec, and made an exclusion of the C:\Users\myname\minikube path in Windows defender, but I still experience the same problem if I use the tcp protocol.

@jim5359

This comment has been minimized.

Show comment
Hide comment
@jim5359

jim5359 Oct 11, 2018

I have exactly the same problem using the same setup (minikube on windows). I've found after 15-30 minutes of idle when I try to access the NFS share it hangs. Sometimes it comes back in a few seconds, sometimes it takes close to a minute, and a couple times it completely froze and I had to kill minikube.

I tried switching to udp and so far I haven't experienced the problem, but surprised there aren't more people complaining about this issue.

jim5359 commented Oct 11, 2018

I have exactly the same problem using the same setup (minikube on windows). I've found after 15-30 minutes of idle when I try to access the NFS share it hangs. Sometimes it comes back in a few seconds, sometimes it takes close to a minute, and a couple times it completely froze and I had to kill minikube.

I tried switching to udp and so far I haven't experienced the problem, but surprised there aren't more people complaining about this issue.

@cbj4074

This comment has been minimized.

Show comment
Hide comment
@cbj4074

cbj4074 Oct 18, 2018

You two are definitely not the first to complain about problems with TCP. For example:

#22
#24

At this point, it might be helpful to use a tool like Process Explorer to examine the hung thread and see if it reveals any clues, such as a specific procedure call, ballooning resource consumption over time, etc.

Also, @pietervogelaar , I would edit the Issue title to include Minikube, as this problem seems to be specific to its use.

cbj4074 commented Oct 18, 2018

You two are definitely not the first to complain about problems with TCP. For example:

#22
#24

At this point, it might be helpful to use a tool like Process Explorer to examine the hung thread and see if it reveals any clues, such as a specific procedure call, ballooning resource consumption over time, etc.

Also, @pietervogelaar , I would edit the Issue title to include Minikube, as this problem seems to be specific to its use.

@pietervogelaar

This comment has been minimized.

Show comment
Hide comment
@pietervogelaar

pietervogelaar Oct 18, 2018

@cbj4074 It's not specific to Minikube, could be any VM on Windows.

pietervogelaar commented Oct 18, 2018

@cbj4074 It's not specific to Minikube, could be any VM on Windows.

@cbj4074

This comment has been minimized.

Show comment
Hide comment
@cbj4074

cbj4074 Oct 19, 2018

@pietervogelaar Have you confirmed that, or are you speculating?

I'm not saying you're wrong, I just don't want to waste anybody's time trying to reproduce the issue when, last we knew, all of the "TCP hanging" issues were effectively ironed-out.

The fact that nobody has mentioned issues with TCP in quite some time, excepting two Minikube users, makes the question relevant, IMO.

cbj4074 commented Oct 19, 2018

@pietervogelaar Have you confirmed that, or are you speculating?

I'm not saying you're wrong, I just don't want to waste anybody's time trying to reproduce the issue when, last we knew, all of the "TCP hanging" issues were effectively ironed-out.

The fact that nobody has mentioned issues with TCP in quite some time, excepting two Minikube users, makes the question relevant, IMO.

@jim5359

This comment has been minimized.

Show comment
Hide comment
@jim5359

jim5359 Oct 19, 2018

Just to add a bit more color: for me, MiniKube is running inside a VirtualBox VM.

Linux minikube 4.15.0 #1 SMP Thu Sep 27 17:28:06 UTC 2018 x86_64 GNU/Linux

NAME=Buildroot
VERSION=2018.05
ID=buildroot
VERSION_ID=2018.05
PRETTY_NAME="Buildroot 2018.05"
NAME=Buildroot
VERSION=2018.05
ID=buildroot
VERSION_ID=2018.05
PRETTY_NAME="Buildroot 2018.05"

@cbj4074's point is valid. I have not tried to reproduce this issue on a non-MiniKube VM, so it's possible it is directly related to MiniKube.

jim5359 commented Oct 19, 2018

Just to add a bit more color: for me, MiniKube is running inside a VirtualBox VM.

Linux minikube 4.15.0 #1 SMP Thu Sep 27 17:28:06 UTC 2018 x86_64 GNU/Linux

NAME=Buildroot
VERSION=2018.05
ID=buildroot
VERSION_ID=2018.05
PRETTY_NAME="Buildroot 2018.05"
NAME=Buildroot
VERSION=2018.05
ID=buildroot
VERSION_ID=2018.05
PRETTY_NAME="Buildroot 2018.05"

@cbj4074's point is valid. I have not tried to reproduce this issue on a non-MiniKube VM, so it's possible it is directly related to MiniKube.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment