Btrfs 0.17 File-System Released

[phoronix]

Phoronix: Btrfs 0.17 File-System Released

The Btrfs file-system was merged into the mainline Linux kernel prior to the release of Linux 2.6.29-rc1, but now a new release of Btrfs is available. It has been about five months since the release of Btrfs 0.16, but version 0.17 has arrived to bring the Btrfs programs in-sync with the file-system's kernel module. The disk format for Btrfs is now believed to be stabilized and will not change unless the developers encounter any "critical issues" now that there should be greater testing of this file-system with it being in the Linux kernel. Version 0.17 of Btrfs brings transparent zlib compression (available through a mount option), improved block allocation routines, improved block sharing while moving extents, and seed device...

http://www.phoronix.com/vr.php?view=Njk4Nw

[Regenwald]

found these (old) benches in the internet:
http://oss.oracle.com/projects/btrfs...benchmark.html
http://www.csamuel.org/2008/03/23/bt...xfs-benchmarks
http://www.csamuel.org/2009/01/04/bt...with-128gb-ssd
http://btrfs.boxacle.net/
http://btrfs.wiki.kernel.org/index.p...ice_Benchmarks
http://www.nuvistor.org/archives/13
http://www.t2-project.org/zine/1/
and so on...sadly, there tests are rather old...
althogh, seem very fast (now we need verification! michael?)
just want to post it before next person ask about btrfs's performance^^
@michael: perhaps you can do some benches, too

[stan]

According to these benchmarks by IBM in October 2008, Btrfs is incredibly inefficient compared to eveything else, especially EXT4.

Last time I pointed this out, people came up with excuses like Btrfs having debug code, etc. I've actually looked at the source, and it doesn't have more debug statements than any other filesystem. Anyway, you'd think they've removed most temporary code now that it's part of the official Linux kernel, and there's really little room for improvement without radical changes.

[snse]

According to these benchmarks by IBM in October 2008, Btrfs is incredibly inefficient compared to eveything else, especially EXT4.

I'm sure those test was made on v0.16. There is many improvements since this time, such as new block allocator.

[snse]

According to these benchmarks by IBM in October 2008, Btrfs is incredibly inefficient compared to eveything else, especially EXT4.

I'm sure those tests was made on v0.16. There are many improvements since this time, such as new block allocator.

[neuron]

Well like any filesystem, it's good at some things and bad at others. You can't expect one filesystem to ace everything. Now from just skimming over the other links posted here it doesnt look terribly good with small files, and ibm's tests are for mailservers.

The reason it gets a lot of publicity is it's ability to do checksuming (which can be extremely important for data safety), mirroring and compression. And the only other filesystem that can do checksuming and compression on linux today is Reiser4.

[stan]

Well like any filesystem, it's good at some things and bad at others. You can't expect one filesystem to ace everything. Now from just skimming over the other links posted here it doesnt look terribly good with small files, and ibm's tests are for mailservers.

The reason it gets a lot of publicity is it's ability to do checksuming (which can be extremely important for data safety), mirroring and compression. And the only other filesystem that can do checksuming and compression on linux today is Reiser4.

What I care about is desktop performance, since I (like the vast majority of Linux users in the world) use computers to write documents, presentations, browse the net, send email, etc. Most those tasks require managing small files, which as you say, Btrfs proves terrible at doing. So Btrfs will most definitely mean a reduced performance for desktop/laptop/netbook users out there.

[Regenwald]

zomfg, just wait until it's ready. there are so much intelligent people working on it, so much firms put money into it, it *has* to get better than ext3/4 etc. for me, it's just a question of time. i'm astonished that's it's already fast in several disciplines (and good i/o).

[neuron]

What I care about is desktop performance, since I (like the vast majority of Linux users in the world) use computers to write documents, presentations, browse the net, send email, etc. Most those tasks require managing small files, which as you say, Btrfs proves terrible at doing. So Btrfs will most definitely mean a reduced performance for desktop/laptop/netbook users out there.

As a desktop user how fast it takes your files text files to load is about 0 anyway. You should be more worried about latency than performance. So that your desktop applications can quickly load tiny files even when heavy io is going on in the background doing something else.

Another thing might be that you require completely different things based on where data is stored. A root filesystem for example should have fast read performance, write performance generally doesn't matter. Therefor a filesystem with compression can result in huge speedups when starting applications.

Another important thing is if you care about data safety btrfs/reiser4 are the only filesystems that provide checksumming on linux atm, which should be far more important for you in your home directory than performance.

[Forge]

So in summary, it's a nice filesystem, 'butterface'!