Date: Thu, 1 Feb 2018 09:48:22 +0100 From: Stefan Esser <se@freebsd.org> To: "Mikhail T." <mi+b@aldan.algebra.com> Cc: freebsd-fs@freebsd.org Subject: Re: Need help with sysutils/fusefs-smbnetfs Message-ID: <cebd24ef-07b6-ebb7-4da3-8f4fcf2f95df@freebsd.org> In-Reply-To: <8868a37f-90ad-a271-2295-bf67164fad19@aldan.algebra.com> References: <8868a37f-90ad-a271-2295-bf67164fad19@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cebd24ef-07b6-ebb7-4da3-8f4fcf2f95df>