Testing Out Btrfs In Ubuntu 10.10

[drago01]

Be careful when testing compression; if your benchmark is just writing out zeros the files of course will compress well and show a huge performance gain; which isn't what you would see in a real world test.

[Jonno]

Actually, it seems like they could probably make the file system smart enough to heuristically stop compressing files that are already compressed (like video) in order to avoid the performance penalty. I don't have any idea if that's already being done or not.

It is, but not very inteligently. The first few blocks are compressed, and the result is used to determine if the entire file should be compressed or not. This doesn't work very well for files that contains both compressed and uncompressed sections, such as disk images and databases...

[ChrisXY]

Think about Atom CPU's and a FS that uses compression, ouch.

I use btrfs + compression on my eeepc, because the hard disk in it is REALLY slow.

It feels like the overall performance did improve a bit but I didn't really test it.
Some operations like updating many packages is slow, but that's acceptable for me.
I mean, what are you doing on an atom pc that needs so much disk activity?

I use mainly Firefox, thunderbird, evince, sometimes eclipse (yes, it is not very good on the little screen) or geany. These are applications that actually do work faster as far as I can tell from my feeling.

[brent]

Without CPU usage numbers, these benchmarks are quite useless.
Also, it would be very interesting to know what the test data that the benchmark programs use does look like. If it is just zeros or an often repeating pattern, this would yield unrealistically good results.

[kebabbert]

Btrfs, once complete, should do pretty much everything that ZFS does and some things that ZFS doesn't.

Do you really expect ZFS development to freeze in time, until BTRFS plays catch up? Just recently ZFS Dedup was added. I wonder what functionality will be added in a couple of years.

BTW, it takes decades to iron out all bugs in a file system. It takes at least 5 years after announcing v1.0 before anyone use it in production. ZFS was officially announced after development in secrecy, and after that it took several years before it was let into production. When BTRFS is v1.0 it will take several years before any trusts it, in production.

As someone said "filesystems should not be sexy. It should be boring and trusted technology" - implying that he will not let ZFS into his computer halls, before at least 10 years has passed and ZFS has become mature enough.

[Drago]

Do you really expect ZFS development to freeze in time, until BTRFS plays catch up? Just recently ZFS Dedup was added. I wonder what functionality will be added in a couple of years.

BTW, it takes decades to iron out all bugs in a file system. It takes at least 5 years after announcing v1.0 before anyone use it in production. ZFS was officially announced after development in secrecy, and after that it took several years before it was let into production. When BTRFS is v1.0 it will take several years before any trusts it, in production.

As someone said "filesystems should not be sexy. It should be boring and trusted technology" - implying that he will not let ZFS into his computer halls, before at least 10 years has passed and ZFS has become mature enough.

Well, file systems are not bottle of wine, to stay in the corner and get better with time. They have to be used to get mature...

[cl333r]

I remember Btrfs works (abnormally) slow with databases and such tests are not present in this benchmark.
To understand what I'm talking about see previous benchmarks on Btrfs.

[Blue Beard]

BTW, it takes decades to iron out all bugs in a file system. It takes at least 5 years after announcing v1.0 before anyone use it in production. ZFS was officially announced after development in secrecy, and after that it took several years before it was let into production. When BTRFS is v1.0 it will take several years before any trusts it, in production.

I disagree --> It takes a very large amount of satisfactory user testing to get acceptance.

Few users --> decades

[subes]

it would be nice to have a cpu load test showing the difference between brtfs and brtfs + encryption

[diegocg]

IOzone writes zeros for its benchmarks, so testing iozone with btrfs compression enabled has zero sense.