Btrfs Is Not Yet the Performance King 117
Ashmash writes "Benchmarks of the Btrfs filesystem have been published by Phoronix that compare it to the XFS, EXT3, and EXT4 file-systems. In the end they conclude that this next-generation Linux filesystem is not yet the performance king. In a great number of the tests, the EXT4 filesystem that was designed to be an interim step to Btrfs actually performs much better than the unstable Btrfs, albeit Btrfs still has more advanced features. Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."
Re:Stability, reliability (Score:3, Interesting)
I'm more interested in a truly distributed file system for making better use of my home LAN full of PCs with those over-sized hard drives that could be being used efficiently.
Several file systems have tried to take advantage of distributed storage, RAID-style, but none are very well maintained or stable or feature-rich for day to day use to my knowledge.
Besides, its a distributed backup system.
Interestingly, it would be easier to store all my data in Freenet [freenetproject.org] and have all my PCs form a darknet with each other.
Re:Stability, reliability (Score:1, Interesting)
I don't care which filesystem is fastest. Kcryptd is the bottleneck on my system, so it really doesn't matter how fast the filessytem is. I want to know which filesystem is the most robust. What filesystem is least likely to lose data?
ZFS
--AC
Re:What will happen to Btrfs (Score:2, Interesting)
Just a quick note about the recently announced purchase of Sun by Oracle. This does not change Oracle's plans for Btrfs at all, and Btrfs is still a key project for us. Please, keep your btrfs contributions and testing coming.
http://article.gmane.org/gmane.comp.file-systems.btrfs/2880 [gmane.org]
Re:Better or Butter? (Score:1, Interesting)
"But her face"
As in, she's so hot...but her face.
No large file unlink() benchmarks? (Score:1, Interesting)
You want to see EXT3 choke and gobble tons of CPU?
Try creating a bunch of 8-20GB files then unlink (rm) the files.
You'll be amazed to see unlink() on EXT3 use 100% CPU usage for 8-20 seconds PER FILE with all of the other processes starved while EXT3 bogs. Any live data collection in other processes will be stalled until unlink() finishes.
XFS, without a real-time volume, does a fine job of large file deletion without bogging the CPU or starving the live data collection processes.
It's too bad Phoronix didn't bother with benchmarking that scenario.
Re:Stability, reliability (Score:3, Interesting)
I can't figure out the "accidentally" add a USB drive to a local disk pool part. Why would mixing removable with non-removable devices in ANY volume manager ever be a good idea, and why would preventing cases where people "accidentally" do so be a priority? When you plug in a USB disk, does a little dialog ask "Would you like to add this removable disk to a logical volume including fixed disks?" Didn't think so.
I know what feature you're talking about, but this attempt to make it a big deal is pathetic.