Btrfs RAID: Linux 3.10 To Linux 3.18 Benchmarks

[liam]

Now it would be good to a benchmark using postresql and/or mysql/sqlite and/or apt.

My perception is that doing an upgrade of a system with btrfs takes like double the time compared to and ext system. I also have the impression that a system with a database also takes a large hit, but that that has improved significantly over time.

For dbtype workloads I believe you're supposed to turnoff cow for the affected file/Dir.
For normal desktop stuff it shouldn't be an issue, but you'd need a good benchmark to prove that.

[nanonyme]

For dbtype workloads I believe you're supposed to turnoff cow for the affected file/Dir.
For normal desktop stuff it shouldn't be an issue, but you'd need a good benchmark to prove that.

Well, even with rawhide also ext you may be able to get more performance out of fs for DB by turning off various file system consistency guarantees like journaling since DB's typically do their own. Seems to me it's only a matter of time until someone exposes fs functionalities so you can build a DB on top of it with minimal overhead

[nanonyme]

Well, even with rawhide also ext you may be able to get more performance out of fs for DB by turning off various file system consistency guarantees like journaling since DB's typically do their own. Seems to me it's only a matter of time until someone exposes fs functionalities so you can build a DB on top of it with minimal overhead

Wow, cell phone corrected royally wrong. Just disregard "rawhide also". I have no idea where that came from

[liam]

Well, even with rawhide also ext you may be able to get more performance out of fs for DB by turning off various file system consistency guarantees like journaling since DB's typically do their own. Seems to me it's only a matter of time until someone exposes fs functionalities so you can build a DB on top of it with minimal overhead

You can certainly do such things with extX, but btrfs let's you do it with much finer granularity.
You may already know this but there've been attempts to model fs on dbs like db2.

[heredoc]

Phoronix: Btrfs RAID: Linux 3.10 To Linux 3.18 Benchmarks

Any feedback or other suggestions is welcome by posting in our forums, contacting me, or tweeting.

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

Could you please test Btrfs-performance when working with VirtualBox-Images?
This famous queue-bug made it unusable for certian kernelversions when working without the "host-i/o-cache".
I'd like to see how it behaves after the several fixes.

You could also see how different settings in VirtualBox change results, like when telling the guest, the disk would be an SSD.

[gigaplex]

I agree a RAID 0 test is of little use to most people. At best it maybe gives some insight into how the more useful RAID levels would perform. I would love to see how BTRFS RAID 10 has performed across versions.

RAID 0 has valid use cases (performance related), and since these benchmarks only test performance (not resiliency), it's perfectly valid to test here. Even if very few people are expected to use it here, it's good to use as a comparison for the other RAID levels to see how close they can get to it in performance.

[Michael]

Could you please test Btrfs-performance when working with VirtualBox-Images?
This famous queue-bug made it unusable for certian kernelversions when working without the "host-i/o-cache".
I'd like to see how it behaves after the several fixes.

You could also see how different settings in VirtualBox change results, like when telling the guest, the disk would be an SSD.

Unlikely as wouldn't generate enough overall interest to justify the number of hours to do such a VBox test configuration, unless lots of donors/premium users requested such testing... Besides not personally being interested much in VirtualBox compared to other virtualization solutions.

[Ardje]

It's still at a proof of concept level. It can't repair itself automatically or detect and drop a malfunctioning drive automatically. Stay away from it.

That's my general advice for BTRFS.
Unless you can lose your data (because you have enough redundancy), do not try it.
If you are going to try it, make sure you always have the latest kernel. Somehow bugs always seem to be fixed in the latest version.
Do not try fsck.btrfs unless your metadata is much less than the memory in your system.

But to be clear: as soon as btrfs shows signs of real stability (as in continuous multithreaded low write pressure, moderate read pressure without corrupting data on disk), I am going to use it, because nothing is better than knowing your copy of the data is correct.