(YNQ™ vs CIFSFS on Linux)

August 25, 2018 by Mark Rabinovich

The SMB (Server Message Block) protocol has widely become the default means of file sharing in local networks, inside cloud spaces or in a heterogeneous environment. The majority of computing forces are now capable of being either an SMB client or an SMB Server and even both. The Linux/Unix world is being, obviously, the most diverse division of those forces as Linux/Unix runs on a wide range of devices from large servers to IoT firmware through desktops, laptops, etc.

Two SMB solutions are the most widely used on Linux platforms.

  • CIFSFS which is a virtual file system granting transparent access to remote shares through the SMB protocol. CIFSFS resides in the Linux kernel and is included in most distributions starting from kernel version 2.5.42.
  • The NQ family of products developed by Visuality Systems originates from the YNQ™ SMB Client and Server for Embedded markets and is empowered by jNQ (Java Client) and NQS (Storage SMB Server). In contrary to CIFSFS, YNQ™ is system independent and runs on tens of different environments. Currently, Linux target platforms compose the majority of YNQ™ installations.

Just to mention one more solution which is libsmbclient developed by Samba Team. Since this product’s positioning is very similar to that of YNQ™, at least from the pure technical point of view, libsmbclient is is not mentioned separately in the comparison below.

Both the CIFS FS and YNQ™ solutions coexist without much antagonism mainly because both depict two opposing approaches of integrating the SMB Client into Linux. Just in a few words the underneath hereunder defines the main differences:

Usage method generic dedicated
Integration level global application
Address space kernel user
Parametrization run-time mostly compile-time mostly
Use cases Workstations
Application servers
Linux-based devices (embedded SMB)
Smart devices

As can be seen from the comparison above CIFSFS and YNQ™ SMB Clients complement each other in terms of the use domains, fine-tuning etc. That is to say that both SMB Clients offer more or less the same features, SMB-wise.


With CIFSFS solution a user just plugs a remote share to the local folder tree and since then he/she can transparently benefit from SMB connectivity through any existing application, being office or a game.

YNQ™, in the contrary, is dedicated to embedded solutions, when SMB connectivity must be granted to a particular code being developed towards a dedicated application, like printer or robot firmware*.

Integration level:

As a part of most Linux editions, CIFSFS is installed together with the operating system and then becomes available system-wide. This solution comes as a kernel module.

YNQ™ comes as a library and must be linked together with the firmware code or application code.

Address space:

CIFSFS resides in the kernel and, therefore, it benefits from being close to the essential services. The word “latency” is widely used in the context of kernel space advantages. A comparison of the kernel-space solution versus user space solutions in terms of latency may bring us too far above the framework of this article. Just to mention that concentrating as much processing as possible in the kernel space is definitely one (but not the only) method of reducing the latency.

YNQ™ resides in the user space as an integral part of the software/firmware application. In contrary to CIFSFS, YNQ™ benefits from being close to the application. For instance, YNQ™ can directly benefit from user-space solutions like DPDK.


As the CIFSFS SMB Client solution comes together with Linux, it has mainly startup or run-time controls. Since this client must provide a generic solution, this seems to be the only way of providing the entire spectrum of possibilities.

YNQ™ provides a dedicated solution. That’s why the most significant YNQ™ controls are applied in compile-time which grants the best tailoring of the SMB Client to the particular application’s requirements. More delicate controls, those that remain inside the application framework, YNQ™ also leaves for run-time.

As one can mention from the above YNQ™ and CIFSF differs in almost everything: from where they reside to whom they serve. Maybe the only match between them is the SMB protocol itself.

Many, many years ago I was frankly convinced that standards will leverage our world making it less diverse and dull. How wrong was I - new standards have raised up but the diversity is still here, e.g., - around SMB.


* YNQ™ is also available through FUSE which makes it more generic and functionally-wise almost equivalent to CIFSFS. However, performance is not the same. Anyway, FUSE usage of YNQ™ is out of this article’s scope.


Please fill in your contact information and the product you would like to evaluate, and a Visuality representative will contact you shortly.