There are quite a number of S3 file systems around. The following table attempts to give an overview. Obviously, it is biased in favor of S3QL because it mainly lists the reasons why the author chose to write a new file system instead of using one of the existing ones.

Please don't hesitate to submit any corrections or additions, I hope that this table will become less biased over time.

Some more S3 file systems are also listed under Related Projects.

There are basically three different types of S3 file systems:

• Block Based file systems expose S3 as a single block device which can then be formatted with an ordinary file system. These file systems are conceptually simple, but the performance is very difficult to get right because they work at a very low level.

• 1:1 file systems save each file in a single S3 object. This has the advantage that the files can be accessed with other S3 tools as well. The disadvantage is that only a very basic functionality can be implemented.

• Native file systems provide the complete set of unix features. They operate at a very high level and can be tailored exactly to the requirements. However, this also makes them very complex and it is very difficult to retrieve the stored data with any other S3 tool.

Notes

• directory rename support: partial means that renaming a directory implies that all contained files and directories need to be copied, so renaming a directory may take a really long time.

• block size: file means that files can only be transferred in one piece, i.e. changing a few bytes in a 1 GB file means that the whole file has to be uploaded again.

• Eventual consistency handling refers to the fact that after an object has been uploaded to Amazon S3, it is possible that downloading the object will still return the supposedly overriden old data. Robust file systems need to be able to handle this properly.

• Multiple Mounts indicates if the same file system can be mounted on several computers at the same time, like e.g. NFS or CIFS.