Bug 193984 - SMBFS transfer very slow and sometimes hangs indefinitely
Summary: SMBFS transfer very slow and sometimes hangs indefinitely
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 10.0-RELEASE
Hardware: i386 Any
: Normal Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-28 06:47 UTC by Jean Cyr
Modified: 2016-10-10 07:23 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean Cyr 2014-09-28 06:47:32 UTC
Server is MS Server 2012, clients are FreeBSD Web 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9.

Copy of large file from server does not exceed 1Mbps over wired GigE. Similar FreeBSD 8 and Linux boxes achieve 20-30Mbps under same conditions. All NICs are Intel and have auto-negotiated to GigE.

Hanging FreeBSD 10 permanently (requires power down, reboot command hangs) can be reproduced as follows:

Copy three large folders recursively in parallel. ie:

cp -R /mnt/SRVR2012/a ~/a &
cp -R /mnt/SRVR2012/b ~/b &
cp -R /mnt/SRVR2012/c ~/c &

Mount done using standard mount_smbfs command.
Comment 1 Jean Cyr 2014-09-28 07:09:27 UTC
In addition when the copies lock up, all three will be in permanent '90wrq' state.
Comment 2 brace01 2016-06-23 02:40:09 UTC
I'm running into the same issue on the latest FreeBSD.

 9642 root          1  20    0 78340K 13476K 90wrq   7   0:06   0.00% rsync
 9644 root          1  20    0 78380K 11544K select  4   0:06   0.00% rsync

The 9642 process cannot even be killed by 'kill -9 9642'.

I'm mounting the Windows 10 share with:

mount_smbfs -N -E UTF-8:UTF-8 -L en_US.UTF-8 -I 192.168.1.197 //BRACE01@COMEX/mu
sic /mnt/vol1/mnt/windows/music

The rsync command is:

nohup rsync -arv -og --delete --chown=816:816 /mnt/vol1/mnt/windows/music/ /mnt/
vol1/jails/subsonic_1/var/music >> /mnt/vol1/cloud1/music_rsync.log &

It runs for awhile but when it gets to the larger files (~100mb each) it gets into this catatonic state as mentioned by Jean.  I've had this work previously but the Windows 10 machine was using a LAN cable and is currently on WiFi.  I'm thinking it might have something to do with this.

Any solutions?
Comment 3 Tomoaki AOKI 2016-10-10 07:23:55 UTC
(In reply to brace01 from comment #2)

Does the latest patch for Bug 90815 [1] help?
If the problem is caused by charset conversion of filename, possibly it helps.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=90815