https://bugs.kde.org/show_bug.cgi?id=291835
--- Comment #54 from Mark <mark...@gmail.com> --- (In reply to Christoph Feck from comment #52) > Mark, the issue is not whether user-space code can saturate the network. The > problem is that there is no async I/O API available in libsmbclient. > > If I understand the previous comments correctly, there is a limitation in > the specification to 64 KB chunks. > > libsmbclient does not allow to send a network request for the next 64KB > chunk while an old one is still running. You have to wait for the reply, > then send the request for the next chunk. On some networks, this causes a > several ms delay between the requests. The faster the transfer speed, the > more painful is the delay (delay vs. payload ratio). > > The CIFS implementation in the kernel does not have this issue; while > created by the same (Samba) team, it does not use libsmbclient and always > requests the next chunk ahead of arrival of the previous chunk, so that the > network is always saturated. > > It would be possible to write a network client out-of-kernel that does not > have the libsmbclient limitation, but we do not have the power to write one. > I do not know if there is any other library or code out there that we could > use. > > > We just need someone > > Not me for anything related to networks or databases ;) I'm fairly sure samba internally uses sendfile when "use sendfile = yes" is set (https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html). However, i'm also quite sure that there were bugs with this and the advice was to have it disabled by default (hence the default is disabled). This must be a bug on the samba side of thigs as sendfile alone works just fine for years now. Just putting "use sendfile = yes" in the config doesn't help though, not in my experience at least. Samba does some weird things there that lose efficiency. -- You are receiving this mail because: You are watching all bug changes.
