A better btrfs

A better btrfs

Posted Jan 26, 2008 13:22 UTC (Sat) by anton (guest, #25547)
In reply to: A better btrfs by masoncl
Parent article: A better btrfs

It's nice to see that Btrfs is going forward. I would really like to see snapshots done properly.

One other feature I would like to see in a file system, and which should be relatively easy to implement in a copy-on-write file system is (what I call) in-order semantics:

The file system after recovery represents all write()s (or other changes) that occurred before a specific point in time, and no write() (or other change) that occurred afterwards. I.e., at most you lose a minute or so of work.

The value of this guarantee may not be immediately obvious. It means that if an application ensures file data consistency in case of its own unexpected termination by performing writes and other file changes in the right order, its file data will also be consistent (but possibly not up-to-date) in case of a system failure

I note that your announcement and the timeline contains a feature "data=ordered support", but it's not clear what kind of consistency guarantee this entails (apart from "preventing null bytes in a file after a crash"). Maybe you can implement in-order semantics as part of the data=ordered support, or add it as another feature to the ToDo list.

---

(Log in to post comments)