Object Storage File System

1. Possible solutions

Object Storage has poor metadata support, and is naturally built for "Write Once, Read More" situations. For example, Object Storage takes extremely longer time to finish object overwrite and object rename operations.
And for a POSIX compatible file system, a lot of features must be supported, not only the overwriting, random access, renaming, file locking, memory mapping, symbol link, etc.
Let's think of how to make the random access works smoothly on a file system based on Object Storage.
The easiest solution is to introducing a normal metadata service together with file chunking techniques.
Just imagine here is one object with 10GB in size. If we introduce the "chunk" or "block" concept and split the object into multiple chunks, then modifying any part of the object will be redirected to modifying the corresponding chunk, not for the entire object.
For example, let's define the chunk size is 1MB, then the 10GB object can be divided into 10240 chunks.
If you need to append a single character to the end of the object, now you only need to:
  • create a new object;
  • write the new character into this object;
  • upload the new object to Object Storage;
  • update the large file's metadata.

That's sounds great, now the behavior is similar with file system built on Block Storage.

But, the problem arises in the meantime:

  1. Firstly, the cost increases greatly. Object Storage charges against the number of requests. In our example, to read the full concept of the 10GB object, we have to issue 10240 requests to the Object Storage.
  2. Secondly, the metadata server becomes the bottleneck. Introducing a metadata server directly implies the increasing cost. Especially, if the metadata server lies on the remote, the network bandwidth may become another performance bottle neck.

 

2. POSIX Compatible

Mapfs, just as the name, it "maps" a remote Cloud Object Storage to local folder or drive.
Mapfs supports POSIX but doesn't support FULL POSIX Semantics. Using mapfs, is just like using a projection/mapping of the remote object storage. mapfs, in the most conditions, follow the object storage's semantics and wraps the semantics in POSIX.
Mapfs works like a POSIX Wrapper of Object Storage.

Mapfs does NOT support the following POSIX features:

  • file locking;
  • Limited support for creation-time, modification time, status change time for a folder;
  • For both file and folder type, mapfs doesn't support creation time, because mapfs is built on libfuse which doesn't support birth-time attribute.
  • Limited support for ACL control:
    • mkdir: default mode is 0777
    • create an empty file: default mode is 0777
    • upload a non-empty file: default mode is 0555