search

osxfuse / sshfs

File system based on the SSH File Transfer Protocol
http://fuse.sourceforge.net
GNU General Public License v2.0
1.14k stars 128 forks source link

sshfs slow (0.2MB/sec) but sftp fast (6.0MB/sec) #57

Open SkyperTHC opened 4 years ago

SkyperTHC commented 4 years ago

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.

  1. Data from /dev/urandom
  2. 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).

bfleischer commented 4 years ago

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.

SkyperTHC commented 4 years ago

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?

SkyperTHC commented 4 years ago

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 notifications@github.com 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 .

SkyperTHC commented 4 years ago

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.

notDavid commented 2 years ago

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

JiamingSuen commented 5 months ago

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
c834606877 commented 3 weeks ago

Just compile the tip verion 2.9 not 2.5( which from brew SSHFS version 2.5 (OSXFUSE SSHFS 2.5.0) ) The speed is ok, and compareable with nginx from another Mac SSHFS version 2.9 FUSE library version: 2.9.9 fuse: no mount point

on my Mac Mojave.

Dont forget install pkg-config before compile. Otherwise you will see this issue:

./configure: line 3796: syntax error near unexpected token `SSHFS,'
./configure: line 3796: `PKG_CHECK_MODULES(SSHFS, fuse >= 2.3 glib-2.0 gthread-2.0)`