Trying to get some help/advice to learn from throughput optimisations in mount.cifs. The major linux desktop projects gnome and KDE are both struggling with throughput performance of their VFS implementations against smb backends. This issue has been going on for a long time. Here are some recently updated bugs: Gnome: https://bugzilla.gnome.org/show_bug.cgi?id=776339 KDE: https://bugs.kde.org/show_bug.cgi?id=291835 The symptoms are that gvfs or kioclient access to smb resources achieves 3 to 20 times less throughput on a particular hardware/network setup than can be achieved by mounting the share using mount.cifs or by using smbclient. Typical throughput of gvfs-smb and kioclient over Gbit networks are only 5-30MB/s whereas mount/cifs and smbclient achieve close to wirespeed, ie > 100MB/s. Both projects use the libsmbclient API (smbc_read/write) , currently with buffer sizes of about 64kB (ref bugs above). The smbget utility also uses libsmbclent, with a default of 64000bytes buffer size. smbget exhibits the same throughput issues as the Desktop VFS implementations. If you pass "-- buffersize=16MB" to smbget, you can get near wire speed (100MB/s). So the discussions have been around increasing buffer sizes, however, understandably, no one is comfortable hard coding a 16MB buffer size. Some users have done tcpdump forensics: https://bugs.kde.org/show_bug.cgi?id=291835#c26 which appear to show that mount.cifs and smbclient do "clever" things like "request 2 x 64kB " and when it receives the first one, asks for the 3rd 64kB block.... which helps keep the wire filled. Is this correct? Does anyone have any recommendations / advice for these 2 desktop projects on which direction to go to improve throughput? Is the brute force approach with "huge ~16MB" buffers the only way given the API that libsmbclent presents, or is there a "smarter" way? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
