In the early 1980s, Motorola released the first commercial mobile phones. They were huge, heavy, cost thousands of dollars, and ran on an analog network called AMPS that was very bandwidth-hungry and lacked basic security features to prevent calls from being tapped or intercepted. As edgy as they were in their day, no one in their right mind would wear them today. When the Motorola DynaTac 8000X was introduced, Sun Microsystems developed its Network File System (NFS) as a protocol that allows client machines to access files on a single centralized server. About the Author Björn Kolbeck is co-founder and CEO of Quobyte NFS was a breakthrough back then, but no one in their right mind would use it today, right? Back then, dial-up connections to modems were measured in bits per second, and local Ethernet LANs maxed out at 10 Mbps. Today we are faced with exponentially more data, faster networks, and more servers than in the 80s or even the 90s. With the advent of scalable architectures in IT, or warehouse-scale computing as Google called it, we've ended up with environments that don't even match the latest and greatest NFSv4. In fact, it has become a handicap. Bigger problem: NFS is designed for a single, centralized server, not for scaling out. Current NFSv4 and even parallel NFS are still based on a centralized model. NFS was not only designed so that clients could talk to a single server, these machines had only a few MB of capacity, relatively small file sizes, and relatively low performance. Every IT manager, CIO, and data scientist in the world has two goals: one, to meet the needs of users and applications to scale, and two, to provide the right data security to ensure security and compliance. and availability. Horizontal scaling requires full mesh (n am) communication between clients and storage servers. Otherwise, there are bottlenecks and bottlenecks to reduce performance, especially in heavy read or write workloads, which are essentially all workloads in a modern enterprise. And that is ultimately its critical flaw: NFS itself is a bottleneck. The NFS device inherently sits directly in the data path and cannot scale throughput to meet compute-intensive I/O demands or multiple concurrent requests. Any gateway is also a bottleneck, and NFS gateways are no exception. NFS gateway-based architectures have severe performance scaling limitations due to cache consistency between NFS gateways to create the illusion of a single NFS server. Because that's all NFS can do, and cache consistency is an expensive aid in running an outdated protocol, rather than fixing the problem: NFS. Load balancing: I use quotes because most of the time the output is far from balanced, it inherently requires a distributed environment or system, and since NFS was never designed for distributed systems, load balancing is tedious and disruptive. You just don't think that way. Ah, but that's where parallel NFS comes into play. People think that it solves all these problems. Unfortunately, pNFS is still broken, and it's still the opposite of augmentation. Only the I/O is distributed among multiple servers; there is still a single centralized server for metadata and control plane. It should come as no surprise that the explosion of corporate data includes a corresponding explosion of metadata. Performance and scale in metadata processing are especially important in big data applications like AI/ML and analytics. Unfortunately, as I see it time and time again, pNFS only solves one small part of the problem: transferring data. It may be the most modern version, but it's 15 years behind the market and leaves many real problems unresolved. NFS also fails during failover. Anyone who uses NFS knows about the "stale file descriptors" problem when an NFS failover occurs. The protocol, even NFSv4, has no idea what failover is (again, it wasn't built to think of it that way), and instead relies on flimsy IP failover, which is slow. . and disruptive. Like many critical features, fault tolerance needs to be designed into a protocol from the start, but NFS added awkward failover later, like a poorly designed building waiting to collapse. This brings me to the second objective of enterprise IT: data security, a general term for data integrity, governance, compliance, protection, access control, etc. Data security is a major concern, whether it's to prevent data breaches or regulate the industry. Recently, data breaches have led to significant fines for companies subject to the European Union's GDPR. Companies that process personally identifiable information or health data must implement industry-leading data protection through encryption. Here again, NFS is a liability because neither pNFS nor NFSv4 offer proper end-to-end encryption, let alone other security mechanisms like TLS and X.509 certificates, all of which are available in today's technologies. storage systems designed for scalability and security, including Quobyte's data center file system. By comparison, NFS represents a serious business and compliance risk. pNFS and NFSv4 also lack end-to-end checksums to identify data corruption. This is also partly a result of the increasing scale of data operations today compared to when NFS was developed. In the 1980s, data integrity using checksums was not an issue, since data transferred over IP packets was small and TCP checksums were adequate. But TCP checksums are now too low, especially at scales greater than 64k per packet. Today, a company expects gigabytes per second. Decades later, NFS still doesn't adequately address data integrity. You are probably underestimating how often you get corrupted data from your NFS storage, and tracking down the problem is difficult and time consuming. Whether it's high performance requirements, random or mixed general workloads, or data access and security, there's nowhere in the modern enterprise where NFS excels.