YNQ vs Samba CIFSFS, CIFS VFS and cifs.ko
The Server Message Block (SMB) protocol has become the default means of file sharing in local networks, cloud and heterogeneous environments. Most connected devices can be SMB client, SMB server or both. The Linux / Unix world represents the most diverse distribution because it runs on a wide range of devices, from large servers to IoT firmware through desktops, laptops, and so on and so forth.
The two most widely used SMB solutions on Linux platforms are:
- Samba – developed from the Common Internet File System (CIFS) Virtual File System (VFS) and the cifs.ko module of the Linux kernel, to grant transparent access to remote shares through the SMB protocol. CIFS VFS is included in most distributions starting from Linux kernel version 2.5.42.
- The NQ family of products – developed by Visuality Systems. It started with the YNQ SMB client and server for embedded systems, written in ANSI C. jNQ (Java-based SMB client) and NQ Storage SMB server followed suit. Contrary to cifs.ko, YNQ is system independent and runs on tens of different environments besides Linux.
cifs.ko and YNQ coexist without much antagonism, mainly because they offer very different integration approaches of the SMB Client into Linux, as represented in the following table:
| Feature | CIFSFS | YNQ |
|---|---|---|
| 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) IoT Smart devices |
| Licensing | GPLv2 | commercial |
As can be seen from the comparison above cifs.ko and YNQ SMB Clients complement each other in terms of the usage, integration, etc. In principle, SMB-wise, both SMB Clients offer more or less the same features.
Usage
With cifs.ko users can plug a remote share to the local folder tree and transparently benefit from SMB connectivity through any existing applications, including business or entertainment programs.
On the other hand YNQ is dedicated to embedded solutions, when SMB connectivity must be granted to a particular code being developed as part of a dedicated application, like printing or robot control.
Side note: YNQ is also available through Filesystem in Userspace (FUSE) interface which makes it more generic and almost equivalent to cifs.ko from a functional standpoint. However, the performance is not the same.
Integration level
As a component of most Linux editions, cifs.ko is installed together with the operating system and becomes available system-wide. This solution comes as a kernel module.
YNQ is a library and must be linked together with the firmware code or application code.
Address space
cifs.ko is located in the Linux kernel 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. Anyway, concentrating as much processing as possible in the kernel space is definitely one (but not the only) method to reduce the latency.
YNQ is positioned in the user space and is an integral part of the software/firmware application. Contrary to cifs.co, YNQ benefits from being close to the application and takes advantage of. For instance, YNQ can directly benefit from user-space solutions like the Data Plane Development Kit (DPDK).
Parametrization
Since the cifs.ko SMB Client comes together with Linux, it has mainly startup or run-time controls, which is suitable to support generic solutions.
YNQ provides a dedicated solution. The most significant YNQ controls are set at compile-time to adapt the SMB Client to the requirements of the specific application. YNQ can adjust at runtime the controls that are internal to the application.
Conclusion
YNQ and cisf.ko differ in almost everything: from their location to their optimal usage. Probably the only aspect that they have in common is the SMB protocol itself.
Standards are intended to streamline work processes, software development, and system-to-device connections. However, despite the introduction of new standards, the landscape of SMB protocol applications remains varied and achieving seamless interoperability between different environments and versions continues to pose challenges.
Lilia Wasserman, VP R&D, Visuality Systems
