Posix vs object storage: How much longer for Posix?

What is Posix?

Posix is the Portable Operating System Interface. It is a set of standards specified by the IEEE and was developed in the 1980s to allow applications to be portable between Unix operating systems.

Its roots are in Unix and it has long been fully certified on the likes of AIX, HP-UX, macOS, z/OS, etc. Numerous other Unix-y operating systems are Posix-compatible, and these include most Linux distributions plus Android. Windows is largely Posix-compliant too, due to the use of environments such as Cygwin.

Why is Posix important to storage?

Posix defines a number of functions that are important to storage, especially in file operations. It defines rules to mount file systems, for file names and – critically – sets rules about access to files, and blocks within them, and notably via hierarchical directory structures.

Posix-compatible file systems have a number of key features. They must implement:

• Strong consistency. So, for example, if a write occurs, a read must return the data written.
• Atomic writes, in which a read returns all data written by a write or none of the data, but never an incomplete write.
• Control access to files using various permissions, including file locking.

In other words, Posix compliance makes sure there are clear rules about how files and parts of files can be written, accessed and read. That helps to ensure the integrity of application operations and transactions. Note that not all OSs are fully Posix-compliant, for performance reasons sometimes, for example.

It is this kind of functionality that makes Posix-compliance so important. It is obvious what it means for ensuring that business processes and transactions have integrity. Most enterprise applications that have been around for any length of time require it, and will have been written around Posix-compliance.

What about object storage and Posix?

Object storage relies on a completely different set of methods for reads, writes, deletes, etc. Instead of a hierarchical file system, objects exist in a flat structure with a unique identifier (instead of a file name). And where Posix file systems have dozens of file system functions, object storage has just a few, such as PUT (a write), GET (a read), DELETE and HEAD (which returns metadata).

With object storage, you can’t get to any blocks and bytes within the object, as you can with Posix-based systems, such as to access data within a database.

Consequently, object storage does not have the same access controls and functionality. And consistency in object storage is “eventual” rather than strong, especially in systems that can be geographically quite dispersed, with multiple versions that replicate over relatively lengthy time periods.

So, to use object storage directly, many enterprise applications would need to be rewritten.

The rise of object storage

While most applications for most of the last few decades have been written as Posix-compliant, the world is changing. Driven by the web and the cloud, object storage is an increasingly important method of holding data.

Object storage has advantages, too. While Posix-compliant systems can become cumbersome and develop increased performance overheads as they scale, object storage scales well and doesn’t suffer a performance lag as it does so.

And although most object storage hasn’t been designed for performance so far, that seems to be changing.

But for now, how can we use objects storage in environments that demand Posix compliance?

Posix-object translation

Some products and projects aim to allow the use of back-end object storage while providing Posix-compliant file system access.

These can be based on methods that store data in an object-based bulk store and bring it to a local file system, where it can be interacted with by Posix-compliant applications.

Examples here include s3ql, which stores all data online in cloud storage services while presenting a local drive with a Posix-compliant file system with features such as compression, deduplication, encryption and snapshots.

Meanwhile, another approach is to use local working storage – based on fast flash in NVMe, for example – in front of the bulk object store and allow object storage to present data for use by applications. The mmap_obj() project – led by Seagate Government Solutions CTO Henry Newman – is an example that potentially does away with the need for a Posix front end to object storage systems.

A productised example comes from startup Nexustorage, based in New Zealand, which allows data to be held in bulk in a local or cloud object storage back end but tiered, according to usage, to local flash storage for its Posix-compliant (or S3) Nexfs file system.