Hacker News Reader

Comment by nine_k | Hacker News Reader

Writing to a file should be transactional. It either succeeds, or gets rolled back. Journaling filesystems implement it as a crash protection mechanism, but an API where you can commit changes without closing, and can roll back explicitly, would be nice.

Writing to a socket is unlike writing to a local file, and cannot offer such guarantees.

View on HN

Seems a lot easier said than done, and would probably incur some costs for something most programs would be largely uninterested in.

Case study: Windows has a feature called "transactional NTFS" which I think may have grown out of the WinFS experiment. They duplicated a lot of filesystem APIs with "transacted" versions. I think the ntdll APIs were a little cleaner than the win32 wrappers - maybe at that layer you can set a transaction on a handle and issue normal fs calls? Anecdotally I heard it was flakey. I believe it's in a sort of deprecated state today.

Journalling protects metadata writes (file names, dates, sizes, permissions, root block allocations) not file content writes, such that a FS can be brought up quickly after a crash. If you want transactional/atomic file ops, you need to implement it yourself on top of existing mechanisms, like transactional databases have been doing for ages.

> Journalling protects metadata writes […] not file content writes

As I understand it, the ext4 file system can have full-data journaling with the “data=journal” mount option (instead of the default, “data=ordered”, which is as you describe).

are there measurable performance hits that you take with transactionality?

Certainly there should be. Not always large; I suppose creating and sequential writing into a new file should be about as expensive as non-transactional.

Reply on news.ycombinator.com