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.
In addition when the copies lock up, all three will be in permanent '90wrq' state.
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
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.
(In reply to brace01 from comment #2)
Does the latest patch for Bug 90815  help?
If the problem is caused by charset conversion of filename, possibly it helps.