Need help with sysutils/fusefs-smbnetfs

[Stefan Esser]

Am 31.01.18 um 19:31 schrieb Mikhail T.:
> Hello!
> 
> I've recently become a user, and then the maintainer of the fuse-smbnetfs
> port. With the mount_smbfs becoming increasingly obsolete, the port seems like
> the only solution for accessing Windows shares from a FreeBSD system.
> 
> The problem is very poor performance. The software uses Samba's libsmbclient
> and thus should be capable of throughput comparable to that of smbclient.
> Unfortunately, the same files I can get here at about 20MB/second with
> smbclient, can only be accessed at about 500KB/s with smbnetfs.
> 
> If I use the "direct_io" flag to mount, the read bandwidth jumps to 5-8MB/s,
> which represents an impressive gain, but is still far below smbclient's
> performance.
> 
> The very fact, that the "direct_io" flag makes such a profound difference,
> made me think, the software's interface with our FUSE implementation may be at
> fault...

Our FUSE kernel code lacks a number of features offered by Linux. This can
be tested by file systems (at compile time, by checking the FUSE kernel
version in fuse_common.h and at run-time by querying for capabilities of
the kernel code, see FUSE_CAP_*).

IIRC, FreeBSD does not provide FUSE_CAP_WRITEBACK_CACHE, for example
(but that should not affect read performance as much as you noticed).

> The upstream developer primarily works with Linux -- and is not very
> responsive at any rate. Can any of the FreeBSD's FUSE-developers take a look
> at the port -- the codebase is not very large -- and suggest any optimizations?

Did you test with version 3 of the FUSE library?

The port should be converted to that version, anyway, since development
of version 2 has stopped. The developer and maintainer of libfuse3 has
made some effort to get it working on FreeBSD (e.g. installed FreeBSD in
a VM for debugging), even though he works on Linux only, in general.

You can contact him at: Nikolaus Rath <Nikolaus at rath.org>

It might be possible to speed up ports that use libfuse3 by adding some
of the features that are disabled due to lack of kernel support (to the
kernel) - but I know that some need changes to system call semantics that
we probably do not want to implement in FreeBSD (e.g. openat(O_PATH), but
that one should not be the cause of any performance problems you see).

> Feel free to contact me directly with any ideas and/or patches.

Sorry, I have no specific ideas or patches to offer. You should identify
the bottlenecks (with libfuse3) and check, whether they are due to missing
kernel features or sub-optimal FreeBSD support in libfuse3. Nikolaus will
probably accept changes to libfuse3 that improve performance on FreeBSD,
since he is interested on seeing it work well on other platforms than Linux.

Regards, STefan