Hacker News Reader

Comment by chrismonsanto | Hacker News Reader

I personally think the biggest problem with current file systems is lack of ACID semantics. It is a tragedy that you can't rollback a set of file system changes if a shell script fails halfway. Why should I have to bring out SQLite if I want transactions, but don't need relations?

(Also I agree--yes MIME types in filesystem please)

View on HN

NTFS supports it: http://en.wikipedia.org/wiki/Transactional_NTFS

Even if such a thing were to exist, it would probably by necessity be built on some lower-level system that doesn't provide such guarantees… like a filesystem.

IIRC in the old Tandem OS transactions were a basic service, even lower level than the file system. So their file system could use the transaction service to perform arbitrary transactions without much complexity. These days all the world's a VAX though.

Depending on exactly what you're doing, ZFS (and probably btrfs?) provide at least the Consistency & Durability of ACID, and maybe Isolation as well. But yes, it seems like it would be relatively straightforward to build Atomicity guarantees on top of a COW-based filesystem. I guess it's unlikely that Oracle would add that to ZFS now though - they don't tend to like discouraging the use of relational databases!

I remember reading some blog post that talked about implementing an InnoDB storage engine using a zfs backend, and using zfs snapshot operations. Seemed to be more of an idea than an actual implementation though.

While ZFS doesn't provide ACID semantics directly, you can achieve similar functionality using zfs snapshots.

Take a snapshot before you make changes in a script, then run the script, if the script fails, just rollback!

Reply on news.ycombinator.com