From owner-freebsd-fs@freebsd.org Thu Feb 1 08:48:44 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23C3CED23E4 for ; Thu, 1 Feb 2018 08:48:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2D167F8E8 for ; Thu, 1 Feb 2018 08:48:43 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout02.t-online.de (Postfix) with SMTP id 0E84141B5888; Thu, 1 Feb 2018 09:48:36 +0100 (CET) Received: from Stefans-MBP-LAN.fritz.box (XjqZbqZbZh9UdN4DSttCJbaDNrb0FbR3h9DZ210kVocK6NGCAIg8UvkkgJpENL+Qhx@[87.151.209.224]) by fwd35.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1ehAXe-1ipV200; Thu, 1 Feb 2018 09:48:22 +0100 Subject: Re: Need help with sysutils/fusefs-smbnetfs To: "Mikhail T." References: <8868a37f-90ad-a271-2295-bf67164fad19@aldan.algebra.com> From: Stefan Esser Cc: freebsd-fs@freebsd.org Message-ID: Date: Thu, 1 Feb 2018 09:48:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8868a37f-90ad-a271-2295-bf67164fad19@aldan.algebra.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: XjqZbqZbZh9UdN4DSttCJbaDNrb0FbR3h9DZ210kVocK6NGCAIg8UvkkgJpENL+Qhx X-TOI-MSGID: 8f87cb29-84f5-4f1e-a908-12ed2bca3974 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 08:48:44 -0000 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 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