Transactional filesystems [LWN.net]

Transactional filesystems

Posted Mar 17, 2009 17:56 UTC (Tue) by butlerm (subscriber, #13312)
In reply to: Better than POSIX? by ms
Parent article: Better than POSIX?

Doing this efficiently requires the adoption of more filesystem internal
transaction processing techniques - meta data undo in particular.

However, "transactional filesystem" usually refers to a much more
complicated setup that allows an arbitrary number of data and meta data
operations to commit or rollback as a group. That is an order of magnitude
more complicated than what would be required to efficiently preserve the
atomicity of file rename operations, for example.

That might well be standard a couple of decades down the road - Google
Transactional NTFS for an example - but for now the ability to provide
atomicity without durability would be a major improvement that has a
fraction of the complexity.

(Log in to post comments)

Transactional filesystems

Posted Mar 18, 2009 15:19 UTC (Wed) by alvherre (subscriber, #18730) [Link]

> Doing this efficiently requires the adoption of more filesystem internal
> transaction processing techniques - meta data undo in particular.

Not so. PostgreSQL, for example, implements transactional semantics without needing metadata undo.

Transactional filesystems

Posted Mar 20, 2009 20:54 UTC (Fri) by butlerm (subscriber, #13312) [Link]

PostgreSQL is not a filesystem. If it was pretending to be one, it would
accomplish what it does by "meta-data" undo, where the meta data of the
higher level filesystem was native to PostgreSQL (i.e. stored in table
rows), as opposed to the completely separate and irrelevant meta data of
the lower level filesystem PostgreSQL was running on top of.

So of course you can implement meta data undo on any filesystem you please,
just as long as the meta data you are referring to is not the meta data of
the filesystem itself.

Transactional filesystems

Posted Mar 21, 2009 18:00 UTC (Sat) by nix (subscriber, #2304) [Link]

I don't see why you can't use MVCC for filesystems, since MVCC could be
regarded as a means of mixing the undo log into the data store itself,
eliminating it as a separate entity.

(As for vacuuming, do it incrementally and the data volume pretty much
doesn't matter; you just work through it bit by bit. PostgreSQL scales to
silly data volumes already...)