ext4 and exfat USB drives very slow with fusefs

ceratoph

Is fusefs the only way to be able to use external drives with these filesystems? Is there no kernel support for this in FreeBSD? I have been testing exfat and ext4 USB drives and it seems very slow (_2MB/s). Typical read speeds on a Linux laptop of the same drives is over 10X faster. And weird things happen like the caja (or PCmanfm) GUI filebrowser shows no files on a drive, but if I type ls at a terminal everything is there.....

So I gave up plugging USB sticks into my ghostbsd and stuck my USB drive in a linux PC and tried to use sftp to transfer files and it was still super slow. Linux-Linux sftp can go about 4-5 MB/sec on my old LAN. Linux-->GhostBSD sftp transfers (of the same files) never exceeed 2MB/sec, which is even slower than fusefs.

Is there something I can do to configure/fix fusefs or sshd for more speed?

vimanuelt

Why FUSE Is Slow on FreeBSD

You’re right, fusefs is typically an order of magnitude slower than native kernel-integrated filesystem drivers on Linux.

Reasons:

Context-switch overhead: Each filesystem operation crosses kernel ↔ userspace boundaries. Every read/write invokes fusefs in userspace, causing many syscalls per operation.
Lack of asynchronous I/O: FreeBSD’s FUSE implementation (sysutils/fusefs-libs + kernel module) does not batch or pipeline requests as effectively as Linux’s.
Mount options: By default, mounts are conservative (no big_writes, small read buffers, strict permissions, etc.), which further slows things down.

Kernel-Level Support (and Limitations)

Unfortunately, for non-native filesystems (exFAT, ext4, NTFS), kernel support in FreeBSD is partial.

FUSE isn’t the only way**, but often it’s the only safe read-write option when you want modern ext4/exFAT features.
If you can tolerate read-only or have legacy ext2/ext3, kernel drivers are faster.

Performance Tuning for `fusefs`

You can improve performance considerably (though not to Linux levels):

Edit /etc/sysctl.conf or runtime test via sysctl:

# Reduce context switching overhead
sysctl vfs.usermount=1
sysctl vfs.fusefs.sync_unmount=0
sysctl vfs.fusefs.data_cache_mode=writeback

When mounting manually, use:

mount_fusefs -o allow_other,big_writes,max_read=131072,async /dev/da0 /mnt/usb

or for exfat-fuse:

exfat-fuse -o big_writes,max_read=131072,async /dev/da0 /mnt/usb

For ext4 (via fuse-ext2 or fusefs-ext4fuse):

ext4fuse /dev/da0p1 /mnt/usb -o allow_other,big_writes,max_read=131072

Expect 2–3× improvement after tuning.

The Caja/PCManFM “No Files” Bug

That’s a gvfs/FUSE cache inconsistency: the file manager uses gvfsd-fuse for user mounts, which can mismatch with mount_fusefs state.
Fixes:

Unmount with fusermount -u /path before remounting.
Disable gvfs auto-mount (pkg remove gvfs) and mount manually via /etc/devd.conf or fstab.
Or, mount drives under /media using root to avoid gvfs interference.

SFTP Slowness

sshd defaults on GhostBSD are conservative for latency over reliability (small buffers, encryption overhead).

Edit /etc/ssh/sshd_config and add:

# Speed tweaks
Compression no
TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 5

Then restart SSH:

sudo service sshd restart

On the client side, use:

sftp -B 65536 user@ghostbsd

or if you prefer scp:

scp -o NoneSwitch=yes -o NoneEnabled=yes -o Cipher=none -l 8192 file user@ghostbsd:/path

(to test raw throughput without encryption).

If network speed remains capped at ₂ MB/s, it’s likely CPU-bound (AES overhead on single core). Try a faster cipher:

sftp -c aes128-gcm@openssh.com user@ghostbsd