sshfs
sshfs copied to clipboard
osxfuse
sshfs slow (0.2MB/sec) but sftp fast (6.0MB/sec)
Hi
From my MacOS workstation to server: 20-40ms latency.
sshfs read-operations are slow at around 0.2MB/sec. sftp download is fast at around 6.0MB/sec.
Same sshfs parameters but using Ubuntu in a VirtualBox running on the same MacOS workstation gives 5.7MB/sec.
'Write'-operations are fast (1.5MB/sec).
Test done with "dd bs=1k if=dumpr.dat of=/dev/null".
I tried two separate test files but that made no difference.
- Data from /dev/urandom
- Data from /dev/zero
I must have tried all options that anyone anywhere mentioned and I never get it above 0.2MB/sec on reads on MacOS.
read/write from MacOS to any sshfs share on my local network is fast (20MB/sec).
$ sshfs -V SSHFS version 2.5 (OSXFUSE SSHFS 2.5.0) OSXFUSE 3.10.6 FUSE library version: 2.9.7
Is this a bug or a feature?
Update: Quick look at tcpdump while MacOS is reading from server via sshfs: Looks like the Server sends just 2560 bytes every 20-60ms. Server sends 1 packet and then waits for the Client (MacOS). The server will only send another TCP packet after it received a TCP packet (not just an ACK but actual data) from the MacOS client.
17:50:00.742403 IP ServerA.64222 > ClientB.55424: Flags [P.], seq 1323001:1325461, ack 24068, win 314, options [nop,nop,TS val 3893591399 ecr 269854967], length 2460
17:50:00.769026 IP ClientB.55424 > ServerA.64222: Flags [.], ack 1325461, win 2048, options [nop,nop,TS val 269855002 ecr 3893591399], length 0
17:50:00.773980 IP ClientB.55424 > ServerA.64222: Flags [P.], seq 24068:24136, ack 1325461, win 2048, options [nop,nop,TS val 269855002 ecr 3893591399], length 68
17:50:00.773997 IP ClientB.55424 > ServerA.64222: Flags [P.], seq 24136:24204, ack 1325461, win 2048, options [nop,nop,TS val 269855002 ecr 3893591399], length 68
17:50:00.774141 IP ServerA.64222 > ClientB.55424: Flags [.], ack 24204, win 314, options [nop,nop,TS val 3893591431 ecr 269855002], length 0
...and then the next 2560 bytes are send from ServerA to ClientB. It's 'stop-and-go' all the way through.
Whereas when I use 'sftp' then the server spits out packet of 8688 length and does not wait for a packet from the Client (the client only replies with ACK's without data content. Very rarely does the client send actual data back to the Server).
You can use the iosize mount-time parameter on macOS to increate the number of bytes that are read or written in one chunk. Usually this increases the I/O throughput significantly. However, it also increase the latency in case of a slow network connection.
I tried iosizes 1k, 4k, 6k 16k, 1M, 4M, 16M and 32M and none of them make a difference in the read speed from the remote system to MacOS. The sshfs read speed remains at 0.2MB/sec compared to Linux 5.7MB/sec and sftp 6MB/sec.
Any other tips?
i found the bug. I submitted a pull request.
the macos kernel reports async reads but only issues sync reads. Work around is to force sshfs to do async -reads even if the kernel claims it's doing it (because the kernel aint).
Can you check and re-release? It'a a major headache for MacOS users at the moment (the forums are full of people complaining how slow sshfs on macos).
I'm now getting 25Mbit/sec to 0.2Mbit/sec without the fix.
enjoy,
skyper
On Fri, Jun 12, 2020 at 7:59 PM Benjamin Fleischer [email protected] wrote:
You can use the iosize mount-time parameter on macOS to increate the number of bytes that are read or written in one chunk. Usually this increases the I/O throughput significantly. However, it also increase the latency in case of a slow network connection.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/osxfuse/sshfs/issues/57#issuecomment-643435300, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNJ2QQQPYXKIDZA3MPWWETRWJ3IHANCNFSM4N4QOGFA .
The bug is in sshfs.c:1827.
The MacOS kernel reports conn->async_read to be TRUE during sshfs_init() but does sync-reads instead (e.g. the kernel never issues more than 1 read and always waits for a response before issuing the next read).
The work around is to force ssh-fs>sync_read = 0 in line 1827.
I've send a pull request reflecting this change: https://github.com/osxfuse/sshfs/pull/58
I'm now getting 25Mbit/sec on reads to a remote server compared to 0.2Mbit/sec without the fix.
Fyi, this fix does not seem to work for me;
35 Mbit/sec with SSHFS versus 330 Mbit/s with Transmit.app. Setting sshfs.sync_read to 0 or 1 does not make a difference...
❯ sshfs -V SSHFS version 2.9 FUSE library version: 2.9.9
macOS 12.3, Macbook M1
For anyone interested in how things are as of 2024, I tried to compile and install the latest version (v2.9) of https://github.com/osxfuse/sshfs and everything works perfectly for me. The transfer speed changed from 4MB/s to 60+MB/s.
During compiling sshfs, I removed https://github.com/osxfuse/sshfs/blob/f187961c7a6a2433c8af7e758d8185568d8006a2/sshfs.c#L17-L19 due to some naming changes.
$ sshfs -V
SSHFS version 2.9
FUSE library version: 2.9.9
fuse: no mount point
