Transactional File Systems

In an article I wrote two years ago I've discusses reasons why to store files in a relational database, based on the premise that file systems are "fast but dumb" regarding transactional features. Journaling file systems are interesting for many reasons, but it does not provide the level of transactions available in the database systems - .e.g. individual transactions are atomic but you can't group them into bigger transactions, it's not possible to do a rollback, you can't use it within an XA transaction, etc. How did the situation change since the time I wrote the article?

Storing files in a database, so that the application gets a proper transactional behavior, is basically just a "workaround" for the inability to do this with the current filesystems directly. I fully admit that storing big chunks of unstructured binary data in a relational database is a bit perverse - first the traditional relational model is designed to work with highly structured data, second the performance of such solution usually is not as good as with a traditional file system (but that depends on the database). A file system with support for transactions (and using it through 2PC transactions) might be a better solution I guess.

Anyway this is just another "chicken or egg" problem - do you want to build a transactional file system on top of a database (that provides the support for transactions), or do you want to build a database on top of a transactional file system? Or should those two things be built separately - DB on top of a traditional non-transactional (journaling) file system, and then a special transactional file system (and use both at the same time using XA transactions)?

I've checked what happened in the field of transactional file systems since I wrote the previous article, and there are few interesting things (and several older I was unaware of too).

Two ways

In general there are two ways to implement transactions when working with files - you can either do that in user space or modify the OS kernel so that it is aware of transactions (at least in case of file systems). Both solutions are possible and have advantages and disadvantages.

In user space

The first option - to build your own transactional file system in user space - was already discussed in the previous article. This approach has the big advantage that it does not influence the rest of the system (not needed to change the implementation of other applications, it does not influence operations of non-transactional operations). It's interesting there are projects to add transactions on top of a non-transactional file system - e.g. Apache Commons Transaction (unfortunately not active since 2008) or libraries like the ancient LIBTP.

However this approach has some diadvantages too. First you have to do that on your own (and it's very difficult to do transactions properly - to get a reliable and efficient implementation, but the good thing is you can customize it to fit the needs of your application). If this solution is based on a relational DB, you will probably run into problems with mixing "unstructured binary blobs" with a beautiful structured relational paradise. If you choose to implement it on top of a simple file system (without a DB), the data will be accessible in the old fashioned non-transactional way too (but by properly setting the access rights the risk may be minimized).

The Apache Commons Transaction looks really interesting - especially if you're using Java to implement the application. I'm a bit worried that the last activity on the project was in 2008 - this means the project either died or is so complete it's not necessary to enhance it (and that usually is not the case).

In the operating system kernel

The second possibility - modifying the operating system kernel so that it works in a transactional manner - is probably "more correct" in principle and fixes most of the disadvantages mentioned when discussing the user space solution. Firstly this is already implemented, tuned and supported solution, built-in to the kernel. Secondly there is no danger of non-transactional access to the data, as all the operations are performed through the kernel.

But this solution has disadvantages too - the most serious one being that I'm not aware of any operating system implementing this (except for a TxOS which is rather a research project than a production system). All the operating systems I'm familiar with are basically non-transactional and support for transactions has to be solved in the user space. The reason for this is the systems were not designed to be transactional and adding this feature would require significant changes of applications due to changes of system calls (extended to support transactions), and concerns this would significantly influence the performance of all applications, even those that do not require transactions.

There are attempts to implement this transactional behavior of a file system (or of the whole operating system), and some of them are actually much older than my previous article. The first first paper Transaction Support in a Log-Structured File System was written in 1993 - it describes an implementation of transactions within a LFS in BSD (based on a log-structured file sytems which is a basis for many current file systems in Linux, designed for flash disks).

Another interesting paper is Extending ACID Semantics to the File System from 2007, describing implementation of Amino file systems (there are links to more papers about this file system on the project page).

And then there are two new papers from 2009 - the paper Enabling transactional file access via lightweight kernel extensions generally does the same as the previous papers, as it describes a file system code named Valor with some transactional features.

The paper Operating System Transactions describing the TxOS project goes one step further, implementing a fully transactional operating system based on Linux kernel 2.6.22. And not just that it one step further than the other papers, but you can get source codes for this one.

Conclusion

So it's not true there's nothing happening in this field - obviously I'm not the only one who would like a transactional file system (or the whole OS).

Links

For completeness' sake I'll list links to the resources mentioned above:

Comments

Transactional NTFS?

Although not a sexy Unix system, is there some reason why you omitted NTFS (TxF)? It does have support for transactional operations and has had for few years.

http://msdn.microsoft.com/en-us/magazine/cc163388.aspx

RE: Transactional NTFS?

Yes, NTFS is the only available transactional file system AFAIK. I'm not sure why I ommited it in the article, but I deal mostly with Unix systems so that was probably the reason.

New comment

All the comments have to be accepted, so there may be some delay between submitting and accepting (or rejecting) the comment. If you enter the e-mail address, you will be informed about acceptance or rejection.

Subject or body may not contain HTML tags - they will be automatically removed. Paragraphs may be separated using a newline (ENTER).

(optional)