Five key points on file locking vs object locking

Locking is strong and well-developed in file systems

File (NAS) and block (SAN) storage both rest on the existence of a file system. NAS storage accesses files directly via the file system, while block storage accesses blocks within the file system, to update parts of a relational database (which itself comprises a “file”), for example.

Windows brought in file locking in DOS which can set file locking by application and user for whole files to restrict access, sharing, reads, writes and deletes, or set byte-range locks for regions of files.

Meanwhile, Unix-like file systems – including Linux – are implemented in different ways from Windows, and can vary between the numerous flavours (you can change open files in Linux, for example). The differences are to do with the ways Windows and Unix-like systems record file information, but essentially they can all restrict access and changes to files as part of the way they are configured.

Object storage lacks built-in locking

Object storage lacks the same forms of developed file locking. That is not to say it doesn’t exist in object storage scenarios; it’s just that it’s not built into the mechanism of object storage in the same way as it is with file systems.

So, for example, it is entirely possible that multiple users can work on the same object at once, and changes will be interleaved and reconciled on an “eventually consistent” basis.

But there are ways that forms of locking are implemented in object storage and the cloud.

File front ends and cloud object locking as partial solutions

Some suppliers offer file access protocol gateways that sit in front of object stores. That way, access to the data is controlled by the forward-facing file system and locking can be deployed. Examples here include Cloudian, Scality and recent startup Nexustorage.

So, for example, cloud providers such as AWS provide object locking with compliance (can never be over-written) and governance (can be over-written with the correct consents) modes that give differing levels of access. Retention periods can be set that keep locks in place until the set date. Meanwhile, legal hold is also possible to stop any changes being made to an object until it is removed.  

Microsoft Azure also has locking for its Blob objects, with the ability to make them immutable, enforce legal hold, etc.

Immutable objects as ransomware protection

It’s not really the same as the locking mechanism in file systems, but recently, object locking has achieved some prominence as a way of quarantining data against ransomware attempts at corruption. Vendors here include AWS, Azure and Wasabi in the cloud, but also Backblaze, Rubrik, Cloudian and Nakivo, among others.

NoSQL databases and locking

The traditionally conceived relational database epitomises the operation of file system locking – of byte regions within a file, in such cases – but more recent NoSQL databases have a better fit to, and are often backed by, object storage.

NoSQL are non-relational databases. They are not used for the most demanding transactional workloads, and in fact can take semi- and unstructured data. So, they can successfully reside on object storage, and they implement their own locking mechanisms.

MongoDB, for example, allows for locking in which requests are queued, while CouchDB has a form of eventual consistency.