The Tux3 filesystem returns

Posted Jan 3, 2013 0:52 UTC (Thu) by butlerm (subscriber, #13312)
In reply to: The Tux3 filesystem returns by kjp
Parent article: The Tux3 filesystem returns

Most databases have to deal with multiple independent transactions, where most filesystems, thankfully, do not. A couple of decades ago almost every database out there would acquire page locks that would block all other page access until the locking transaction was committed.

You can just imagine if access to a directory stalled because another pending transaction had an uncommitted modification to the same directory. Or if pending additions to a directory had to be invisible to other readers, data writes had to be invisible to other readers until committed and so on. There are ways to solve that problem in database system design, but fortunately filesystems generally speaking don't have to deal with it.

The Tux3 filesystem returns

Posted Jan 3, 2013 8:11 UTC (Thu) by daniel (guest, #3181) [Link] (1 responses)

Filesystems actually do need to deal with multiple independent transactions because of shared resources like bitmaps and the inode table. We need to ensure that for each delta the bitmaps exactly match the file data and directory entries exactly match the inode table, and do that without holding long duration, performance killing locks.

The Tux3 filesystem returns

Posted Jan 3, 2013 16:33 UTC (Thu) by butlerm (subscriber, #13312) [Link]

A modern database deals with multiple long lived independent transactions that can independently be committed or rolled back, involve independent, isolated views of what the contents of the database look like that evolve as each transaction progresses, row level locking so that no more than one uncommitted version of a row exists at any given time, and multiple version concurrency control so that all other readers only see the previously committed versions of rows.

POSIX filesystem semantics don't have anything like it - in fact they actually forbid it. There is only one view of the filesystem to all user processes, and everything that happens takes effect instantaneously. No isolation, no process specific view of the contents of files or directories, no (user visible) transaction commit or rollback.

Everything a strict POSIX filesystem does with transactions is for recovery purposes, in an attempt to recreate something resembling a consistent snapshot of the system at the time it failed, or at least a working inconsistent one. And certainly one would want to pipeline the assembly and retiring of those transactions, so that the next one can be constructed while previous ones are being retired. I am glad to hear that Tux3 does just that.