"Btrfs v0.16 is available for download," began Chris Mason, announcing the latest release of his new Btrfs filesystem. He noted, "v0.16 has a shiny new disk format, and is not compatible with filesystems created by older Btrfs releases. But, it should be the fastest Btrfs yet, with a wide variety of scalability fixes and new features." Improved scalability and performance improvements include fine grained btree locking, pushing CPU intensive operations such as checksumming into their own background threads, improved data=ordered mode, and a new cache to reduce IO requirements when cleaning up old transactions. Other new features include support for ACLs, prevention of orphaned inodes so files won't be lost after a crash, and a more robust directory index format. Chris noted:
"There are still more disk format changes planned, but we're making every effort to get them out of the way as quickly as we can. You can see the major features we have planned on the development timeline. [...] the btrfs kernel module now weighs in at 30,000 LOC, which means we're getting very close to the size of ext[34]."
From: Chris Mason
Subject: Btrfs v0.16 released
Date: Aug 5, 12:01 pm 2008
Hello everyone,
Btrfs v0.16 is available for download, please see
http://btrfs.wiki.kernel.org/ for download links and project
information.
v0.16 has a shiny new disk format, and is not compatible with
filesystems created by older Btrfs releases. But, it should be the
fastest Btrfs yet, with a wide variety of scalability fixes and new
features.
There were quite a few contributors this time around, but big thanks to
Josef Bacik and Yan Zheng for their help on this release. Toei Rei also
helped track down an important corruption problem.
Scalability and performance:
* Fine grained btree locking. The large fs_mutex is finally gone.
There is still some work to do on the locking during extent allocation,
but the code is much more scalable than it was.
* Helper threads for checksumming and other background tasks. Most CPU
intensive operations have been pushed off to helper threads to take
advantage of SMP machines. Streaming read and write throughput now
scale to disk speed even with checksumming on.
* Improved data=ordered mode. Metadata is now updated only after all
the blocks in a data extent are on disk. This allows btrfs to provide
data=ordered semantics without waiting for all the dirty data in the FS
to flush at commit time. fsync and O_SYNC writes do not force down all
the dirty data in the FS.
* Faster cleanup of old transactions (Yan Zheng). A new cache now
dramatically reduces the amount of IO required to clean up and delete
old snapshots.
Major features (all from Josef Bacik):
* ACL support. ACLs are enabled by default, no special mount options
required.
* Orphan inode prevention, no more lost files after a crash
* New directory index format, fixing some suboptimal corner cases in the
original.
There are still more disk format changes planned, but we're making every
effort to get them out of the way as quickly as we can. You can see the
major features we have planned on the development timeline:
http://btrfs.wiki.kernel.org/index.php/Development_timeline
A few interesting statistics:
Between v0.14 and v0.15:
42 files changed, 6995 insertions(+), 3011 deletions(-)
The btrfs kernel module now weighs in at 30,000 LOC, which means we're
getting very close to the size of ext[34].
-chris
--
Roadmap of btrfs features post 0.16
http://thread.gmane.org/gmane.comp.file-systems.btrfs/1011
Funny
One guy is showing of counting lines and just below Linus in quoted saying
'Have you guys looked at the size of the kernel lately? Bloat is bloat.'.
That said I'm *really* looking forward to test btrfs.
md replacement?
The page here mentions "Integrated multiple device support, with several raid algorithms" as a "main btrfs feature."
It sounds like btrfs is going to have its own implementation of RAID, independent of Neil Brown's md layer. I wonder if the md guys are going to be upset by this?
I suppose then Linux users will have three different ways to get RAID 0 functionality: by creating an LVM volume spanning multiple disks, by using the md layer with RAID 0, and by using btrfs with integrated multiple device support.
I hope that btrfs does a better job than the md layer of dealing with failing disks. When disk I/O starts timing out, the md layer just allows the device driver to keep trying and retrying for *minutes* at a time. Even if you have 5 hot spares sitting around, it will just keep grinding away, until the device driver finally declares the disk dead. Meanwhile, your server has been brought to its knees, defeating the whole point of RAID in the first place.