...and another thing. Both ZFS and Btrfs have lots of features that are not present in EXT4. Some of them, such as indexing and dynamic volume management, can degrade performance. So knowing what is enabled and what is not, is also important. Does ZFS have more such features enabled by default etc?
It is very syntethic benchmark. In reality anyone using zfs will probably use many disks probably with configuration of at least two HDD and one SSD as secondary cache and intent log.
But benchmarking such configuration is also pretty hard. Benchmark would need many hours to run, to fill cache and see difference.
Anyway nice to see benchmark of modern file systems!
This is meant for desktop users. Just as mentioned in the rotating hdd benchmark thread, most users crying for btrfs or zfs and its features like snapshotting are actually single drive desktop and laptop. Yum's adoption of btrfs snapshotting is one good sign those kind of file systems will be used in ordinary desktops. There will probably be much more ordinary users using it on laptops than advanced users on multi-drive machines, just because there is so much more laptops out there.
Congratulations to BTRFS. Personally, I dont care about speed. Is my data safe? That is the most important thing to me.
Would you prefer a cpu which is very fast, but does some miscalculations, or a slower cpu which always do correct calculations?
ZFS seems to be safe, according to researchers. XFS, JFS, ReiserFS, Raid5, Raid6, etc - all are not safe according to research. We see that it is very difficult to make safe storage solutions. There is no research on BTRFS data safety, so we have to wait for research. But now BTRFS is under development and under heavy revision where things are changed all the time, so we have to wait for finalization too.
oh no, here we go again ^^^
BTRFS is very fragile at this time. Its so easy to break the FS and DOS the system. A normal user can do it. You can make it (I am talking 2.6.35.X code) throw ENOSPC with most of the space intact by just creating a couple big files, many small files and then deleting the big files. For exact steps see the bug: https://bugzilla.kernel.org/show_bug.cgi?id=16508
Originally Posted by kebabbert
No attention from devs on that as yet. You can read more about it at: http://forums.gentoo.org/viewtopic-t...ighlight-.html
And for reliability, have a read of: http://forums.gentoo.org/viewtopic-p...2.html#6338202
Also, read about excessive idle IO at: http://forums.gentoo.org/viewtopic-t-834065.html
I was a self-professed BTRFS fan and had it on my "/" for quite a while but it changed over time as I kept finding issues with it and kept reading the issues reported at the BTRFS mailing list and reading developers' responses. It would take a long time for me to trust my data to this FS again.
I don't disagree it's 'rough around the edges' when it comes to data security.
Oh course it is, no real surprise there....
My comment has to be understood in the context of the 'evangelism' of said users prior commentary
I am not really a ZFS evangelist (I was a BTRFS evangelist: see my posts on gentoo BEFORE I ran into issues and started digging deeper) but I think ZFS is a production ready full-featured FS. I have used it on Solaris as well as Linux (through FUSE). Its a solid FS. I couldn't break it.
Originally Posted by jalyst
BTRFS is a baby in comparison, both in terms of features and stability. Its good and nice to claim data integrity because of block level checksums, but what good is a block checksum if you can't use it and warn users of the corruptions and/or rectify the corruptions. Again, see my post regarding how I ran into hidden corruptions on BTRFS and, FS access as well as btrfsck (which DOES NOT do anything at the moment I found later) didn't do anything.
BTRFS has miles to go! Dig deeper folks! Don't go by XYZ said so. Use the damn thing, and break it! See if it can pass the normal data integrity tests. And read BTRFS mailing lists once in a while!
Tags for this Thread