A better btrfs

Posted Jan 17, 2008 15:59 UTC (Thu) by masoncl (subscriber, #47138)
In reply to: A better btrfs by Klavs
Parent article: A better btrfs

Working nicely with LVM is a long term goal for Btrfs.  However, Btrfs will (optionally)
maintain duplicate copies of metadata so that it can find a valid copy when it notices
checksumming errors, or errors reading from the device.

This is something LVM cannot provide because it cannot maintain consistent checksums for the
FS.  Also, many admins will want to enable metadata mirroring even on single volume
filesystems where LVM isn't used.

When multiple devices are present, Btrfs will want to know it is mirroring on different
physical spindles.  This is a challenge with LVM since the locations of physical extents can
change without the FS knowing about it.  Even if there were hooks so the FS could know the
current extent mappings, it would end up duplicating a copy of the mappings internally.

So, the storage pool features are not trying to reimplement MD/LVM, but they are trying to
carve out the critical features that LVM cannot provide as efficiently as the FS can.  

Multipathing, raid3/5 etc, dm-crypt and most of the other fun things you can do with the
storage stack are not planned Btrfs features...

(Log in to post comments)

A better btrfs

Posted Jan 26, 2008 13:22 UTC (Sat) by anton (subscriber, #25547) [Link]

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.