Released in the late 1980s, POSIX (Portable Operating System Interface) is a family of standards created to make sure that applications developed on one UNIX flavor can run on other UNIXes. The POSIX standard describes how system calls must behave. One particular section of the standard defines the semantics (behavior) of a POSIX compatible file system. Today, many of the UNIX systems that existed back in the 80s and 90s have become irrelevant. On the other hand, Linux became ubiquitous; one of the reasons being the POSIX compatibility. Being POSIX compatible made it easier to move from a UNIX to LINUX.
For a file system to be compatible with POSIX, it must:
As you can see in the diagram above, your application makes system calls such as open, read, and write to communicate with the Linux kernel. The semantics, i.e., the behavior, of the system calls is defined by POSIX.
The Linux Kernel hands the file system-related system calls to the Virtual File System (VFS) layer, which abstracts from the underlying file system implementation, which includes local file systems but also distributed file systems like Quobyte.
Because of POSIX compatibility, you are no longer tied to a single file system. Suppose you decide to start using a specific file system, and all of a sudden, the creator of that file system gets incarcerated, and the file system becomes irrelevant (as random as this may sound, this actually happened with ReiserFS and its creator!). Even in a very random case like the one mentioned before, you don’t have to worry because you can easily swap out the file system without worrying about your application having problems with the new file system.
Linux is seen as "partially POSIX compatible" when it comes to the file system, mainly because it doesn't provide the isolation feature that POSIX requires for IO operations. Instead, reads and writes are atomic on a page level (4kB), but a read might return some pages of a concurrent write operation. The decision not to implement atomicity is mainly due to performance. Instead, applications have to use file locking if they expect concurrent read/write access and require isolation between them, e.g., to avoid reading incomplete writes.
The POSIX standard was initially developed for local file systems, but when accessing and sharing a file system over a network, we suddenly had to deal with a range of challenges like cache consistency or concurrent access from multiple clients. The strong consistency requirements of POSIX make caches infeasible and require expensive cache consistency protocols between clients.
In contrast to POSIX, the NFS (Network File System) protocol allows for more lenient consistency, which guarantees increased performance. Local caching is allowed until a file is closed, flushed, or a lock is released on the file. This semantics is sometimes called unlock-to-lock and close-to-open consistency.
Distributed applications that concurrently read and write to the same file without locking or close/open will read stale data from the local caches. However, most distributed applications use locks to coordinate access, which causes NFS to flush caches and read from the actual source.
To get the best of both POSIX and NFS, Quobyte offers a distributed parallel POSIX compatible file system that runs any Linux application natively, giving you the same consistency guarantees as NFS.