Discussion:
Problems using mounted Windows 8.1 share
Jarno Malmari
2014-01-13 19:55:49 UTC
Permalink
Windows 8.1 and Server 2012 R2 shipped with SMB v3.02 and that's the
only relevant part I can see what can be the cause that my CIFS mount
stopped working properly. Problems showed up after upgrade from
Windows 8 to 8.1. (SMB v3.0 -> v3.02)

What use to be smooth user experience is now laggy. Copying 250KB or
1MB file with cp can take 60 seconds, consisting of multiple ~10
second pauses between reads. This applies to other commands as well,
even to those that do not read too much data like "file". Sometimes I
see weird errors from system (translated error message: "machine is
down") in stdout or stderr. No idea where they come from. To make
things difficult, sometimes the commands work ok, although I'm quite
sure they used to be faster.

No errors in syslog, even with CIFS debug output enabled. At least to
my unexperienced eye.

Any experiences with this?


In case it matters, my fstab says:
//server/share /mnt cifs
user,noauto,soft,credentials=/path/to/credsfile,rw 0 0

Also probably worth noticing is that the Windows lives in a virtual
machine and communicating via dedicated vmware private network
(vmnet1).

Thanks!
--
Jarno
Jeff Layton
2014-01-15 13:28:16 UTC
Permalink
On Mon, 13 Jan 2014 21:55:49 +0200
Post by Jarno Malmari
Windows 8.1 and Server 2012 R2 shipped with SMB v3.02 and that's the
only relevant part I can see what can be the cause that my CIFS mount
stopped working properly. Problems showed up after upgrade from
Windows 8 to 8.1. (SMB v3.0 -> v3.02)
What use to be smooth user experience is now laggy. Copying 250KB or
1MB file with cp can take 60 seconds, consisting of multiple ~10
second pauses between reads. This applies to other commands as well,
even to those that do not read too much data like "file". Sometimes I
see weird errors from system (translated error message: "machine is
down") in stdout or stderr. No idea where they come from. To make
things difficult, sometimes the commands work ok, although I'm quite
sure they used to be faster.
No errors in syslog, even with CIFS debug output enabled. At least to
my unexperienced eye.
Any experiences with this?
//server/share /mnt cifs
user,noauto,soft,credentials=/path/to/credsfile,rw 0 0
Also probably worth noticing is that the Windows lives in a virtual
machine and communicating via dedicated vmware private network
(vmnet1).
Thanks!
cifs.ko doesn't currently autonegotiate smb2+ connections. You have to
explicitly request them, so you're likely still using smb1 with the
above fstab entry.

If you're getting -EHOSTDOWN errors back, then it sounds likely that
you're losing connectivity to the server. If updating the server
changed something then it's likely that that's where the problem is.

I'd take a hard look at whether connections are getting dropped by the
server and why...
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
Jarno Malmari
2014-01-17 11:20:42 UTC
Permalink
Post by Jeff Layton
cifs.ko doesn't currently autonegotiate smb2+ connections. You have to
explicitly request them, so you're likely still using smb1 with the
above fstab entry.
If you're getting -EHOSTDOWN errors back, then it sounds likely that
you're losing connectivity to the server. If updating the server
changed something then it's likely that that's where the problem is.
I'd take a hard look at whether connections are getting dropped by the
server and why...
Thanks for the pointers and steering me away from SMB. I was able to
reproduce the issue (sometimes) over a plain TCP connection. I highly
suspect a driver issue on the server machine.

Anyhow, not CIFS related. Case closed.

Continue reading on narkive:
Loading...