• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Btrfs vs. ZFS

jwcalla

2[H]4U
Joined
Jan 19, 2011
Messages
3,628
Let's all have a hearty laugh and pretend for a moment that Btrfs will be ready for primetime later this year.

Who will be switching over?
 
probably no one since it will most likely come with basic features.
plus we want to wait at least a year for other people to play with it to make sure that it's stable.
and we need to wait for some interface to manage it (does an interface exist?), unless you want to do it all via the terminal.

in 3 years I will probably switch, but not this year.
 
I am using it as the OS drive on 1 system and to hold VMs on a second at work.


it will most likely come with basic features.

Agreed. Only raid 0, 1 or 10. And I am not sure if the fsck is even considered released yet. It's going to be years before this filesystem becomes as functional as zfs is today.
 
I understand that the fsck should be coming shortly.

Is there any functionality that Btrfs, when completed, won't have that ZFS does? The Wiki page seems pretty optimistic.

I also think that the schedule for release is pretty optimistic too. Like was said, you also need some time to iron out the bugs before really taking it seriously.

As nice as Linux is, I think I'll just focus on ZFS.
 
Is there any functionality that Btrfs, when completed, won't have that ZFS does?

I do not think so. However the key is when completed. At the current development rate I am not expecting it to be completed before 2015. Although if it becomes the base fs for some of the big name distributions perhaps more people will actually work on it.

The Wiki page seems pretty optimistic.

I am not sure the wiki has changed much in years.
 
The best hope is for a big corporation to adopt it. Kinda like how Apple were rumored to use ZFS. Windows is moving to ReFS which besides using b-trees is nothing to get excited about.
 
ZFS is now 10 years old, and STILL they find bugs in it. There are sysadmins today that think zfs is too new and unmature, ten years after v1.0 release.

When btrfs is released as v1.0 it will take ten years before it gets stable enough to be used in production. When will v1.0 come?

I believe MS Windows ReFS will come to market before btrfs, with more functionality. ReFS has checksums for metadata, but not for the data itself, alas.
 
The best hope is for a big corporation to adopt it.

That's kind of the interesting part. Oracle was pushing Btrfs but once they acquired Sun and decided to push the whole Sun package, they probably lost interest in Btrfs pretty quickly. Though it appears progress is still being made on a regular basis.
 
They do pay Chris Mason to work on this however it seems way more involvment is needed to get this going at a reasonable pace.
 
If btrfs is going to take that long, why not just wait for zfs kernel functionality in linux?
 
Yeah, I know about that project. Are you talking about the original licensing issue that keeps the original ZFS from being included in linux kernel? If I recall, that is a fundamental conflict between sun's cddl and the gpl - that's why (AFAIK) they had to start this 'from scratch' port. Even so, it's still better than waiting N years for a 'sorta similar' system (btrfs), IMO.
 
Yeah, I know about that project.

What worries me most about that project is the dependence on the developers to keep to a reasonably current kernel. At work I have been burned more than once from out of source kernel module development. One such instance is I used openvz for years then at some point they stopped updating kernels and stuck to RHEL kernel releases which to me does not work well at all for me since I am not using RHEL.

Are you talking about the original licensing issue that keeps the original ZFS from being included in linux kernel? If I recall, that is a fundamental conflict between sun's cddl and the gpl - that's why (AFAIK) they had to start this 'from scratch' port.

Yes. To me its very frustrating that this licensing was not changed to eliminate this issue altogether.
 
How could it change? ZFS was done under the Sun CDDL. Sun no longer exists, and frankly, I can't see Oracle saying "sure, we will release ZFS from the license it is under..."
 
Oracle has the power to change the license since they acquired Sun and all of its technologies. They do not want to do that. They do however support Chris Mason and his efforts to develop btrfs although without more resources (I know there are others working in this) the development is going pretty slow.
 
I believe MS Windows ReFS will come to market before btrfs, with more functionality. ReFS has checksums for metadata, but not for the data itself, alas.

Could you elaborate on this? I keep hearing this statement on a couple of forums but can't quite figure this out. Wouldn’t ReFS be worthless if there wasn't checksums on all data? Or there is a nuance in the terminology that I getting hung up on?
 
Could you elaborate on this? I keep hearing this statement on a couple of forums but can't quite figure this out. Wouldn’t ReFS be worthless if there wasn't checksums on all data? Or there is a nuance in the terminology that I getting hung up on?

Checksum protection on data is optional, but is an feature - it's automatic on metadata. The stranger issue now is that this appears to only work with mirrored, but not "raided" volumes.
 
They are confident it will be released. However it will not have all the planned features. I would not expect raid 5 or raid 6 to be marked stable for some time that is if the 2009 patches that add this get merged soon. Same goes for other more advanced features.
 
Is there any functionality that Btrfs, when completed, won't have that ZFS does?

There is one thing I have not seen yet. I have not seen any mention of triple parity raid like raidz3 although I would expect that in the future.
 
Checksum protection on data is optional, but is an feature - it's automatic on metadata. The stranger issue now is that this appears to only work with mirrored, but not "raided" volumes.

Why does it matter if it is optional vs automatic? Shouldn't the user (admin) have a choice in the level of integrity on their data?

On the "stranger issue", why does this matter? Would it not be preferable, for those of us in the window enviroment, at least have some level of protection now vs being exposed for a longer period of time?

I honestly don't want to get into a bitch fest of ZFS vs the world. But it appears that people that are shunning ReFS are doing so from the point of "it's not ZFS" which is bothersome. With that logic...we shouldn't have android powered phone and be happy with what Apple gives us.

The real questions on ReFS that must be answered are:
  • Does it do what it said it would do
  • Does it provide sufficient value to the target audience
If the answer is yes on both fronts, then it is valid product. The same goes for Btrfs, etc. Now on the whole maturity argument...that is again, a matter of your requirements. If the ancient data systems of yesteryear are the only way to meet your requirements..then that is the correct choice. But to, again, declare invalid, newer products based on that isn't fair or wise. Might as well record all data on stone tablets, in redundancy, in 7 different locations on the plannet, burried 500 feet in a salt vault.
 
The point is not that "old is good", but rather that a filesystem that does not have a LOT of mileage out in the field is not trustworthy.
 
Years ago i have had a Windows 2003 mailserver. Someday a user got read errors on some mails. I had no time to look at. A few days later more users got problems. I decided to do a checkdisk (offline, needed time more than half a day). I then got errors on errors with the result of an quite unusable array and the need to use a backup with a data loss of newest mails of that day and a downtime of two days.

At home i have a vdr linux system that i sometimes powered off without prior proper shutdown with the result: os reeinstall needed.

With these experiences in mind i discovered ZFS at a time it was very uncomfortable for me (coming from Mac, DOS, Win, Novell), indeed it was Apple who thought about ZFS these days, so i looked at too. It took about one year of learning and improvements in NexentaStor 2 until I was ready to move all my filers to ZFS. Maybee I have not done with btrfs or refs. But now, its absolut not an option. ZFS is already far ahead. But for those not able or willing to use Solaris/FreeBSD or ZFS it may be a huge improvement. But to be honest. I count for ZFS also on Linux (and now on OSX with zevo from Ten's Complement). ZFS is not only the most advanced but the universal filesystem now (outside Windows that is behind even with the upcoming refs regarding the filesystem)
 
Last edited:
ZFS is not only the most advanced but the universal filesystem now (outside Windows that is behind even with the upcoming refs regarding the filesystem)

I don't know how you can say universal and exclude windows.
 
Why does it matter if it is optional vs automatic? Shouldn't the user (admin) have a choice in the level of integrity on their data?

Well, in my opinion no - it should be validated by default - but I don't think I expressed a preference on that.

On the "stranger issue", why does this matter? Would it not be preferable, for those of us in the window enviroment, at least have some level of protection now vs being exposed for a longer period of time?

You are really reading into my post very, well, strangely.. It's not that windows shouldn't have full checksum protection, or shouldn't have automatic correction/scrubbing in mirrors. It's that it's strange that it doesn't have so in raided volumes.

I honestly don't want to get into a bitch fest of ZFS vs the world. But it appears that people that are shunning ReFS are doing so from the point of "it's not ZFS" which is bothersome. With that logic...we shouldn't have android powered phone and be happy with what Apple gives us.

Huh? I'm not shunning ReFS - I've just said that I find it really strange that you don't get any benefit from data checksumming in raided volumes.

If I say "it annoys me that we don't have block pointer re-write in ZFS and so can't expand vdev's" that doesn't mean I am shunning ZFS - that just means I find something quirky about it.

As for ReFS, from what I've read (since I haven't used it) it sounds like a great step in the write direction - but for raid (not mirror type setup) it seems to be missing critical features - data file integrity via checksum (it's there, just not "turned on") and no multi-parity drives being the two big ones (you want to run a 10 disk array with 1 parity drive?)

That doesn't mean it's never going to get there - MS has a tremendous amount of expertise and skill in programming and I"m sure will turn something out - if management steers them in that direction.

That doesn't change the fact that - as it stands now - from a "i don't want to loose or corrupt my data" standpoint it's significantly worse than ZFS, and worse than raid-6 cards as well - if you aren't running a mirrored or raid-10 type setup. Which means for most of the people here running home type servers it's a non-starter. At least until the next point release.

The real questions on ReFS that must be answered are:
  • Does it do what it said it would do
  • Does it provide sufficient value to the target audience
If the answer is yes on both fronts, then it is valid product. The same goes for Btrfs, etc. Now on the whole maturity argument...that is again, a matter of your requirements. If the ancient data systems of yesteryear are the only way to meet your requirements..then that is the correct choice. But to, again, declare invalid, newer products based on that isn't fair or wise. Might as well record all data on stone tablets, in redundancy, in 7 different locations on the plannet, burried 500 feet in a salt vault.

If you are running a large raid array it puts your data at significant risk (no multi parity), and there is the bit rot issue as well (only checksummed in mirrors). If you consider that acceptable - well that's a personal value call, but for a raid type setup I can't see any reason to consider it. If you don't want ZFS a raid-6 add in card would be much better.

I don't think anyone declared it invalid - you sort of put those words in our mouths - but I still would agree that for a typical raid type home server it is a poor choice. Do you think ReFS is a good fit for the guy with a 10 disk raid-z2 array currently? What do you think he is gaining over it. I'm also curious, you are alluding to ZFS as "an ancient data system of yesteryear" - what features of ReFS are you comparing it to that make it seem dated at ReFS advanced?
 
You are really reading into my post very, well, strangely.. It's not that windows shouldn't have full checksum protection, or shouldn't have automatic correction/scrubbing in mirrors. It's that it's strange that it doesn't have so in raided volumes.

Possibly this is another step to prevent users from using desktop operating systems in server roles.
 
Possibly this is another step to prevent users from using desktop operating systems in server roles.

Except this is a windows 8 *server* feature - not available in windows 8 (non server).

My strong suspicion is that it's just a feature that didn't make it into v1 and will be added later. I expect MS takes a new filesystem seriously and probably is being very conservative in how much they bite off at the beginning.
 
I thought ReFS was going to be used on the desktop OS. Hmm. Completely missed that one. Sorry for the noise..
 
If I say "it annoys me that we don't have block pointer re-write in ZFS and so can't expand vdev's" that doesn't mean I am shunning ZFS - that just means I find something quirky about it.

Yes, when is that coming? They said years ago that it was ready.
 
Regarding ReFS in Windows 8. It only supports checksums on metadata, but the data itself might be corrupt:
http://blogs.msdn.com/b/b8/archive/...-generation-file-system-for-windows-refs.aspx
" Metadata integrity with checksums
Integrity streams providing optional user data integrity"

"As mentioned previously, one of our design goals was to detect and correct corruption. This not only ensures data integrity, but also improves system availability and online operation. Thus, all ReFS metadata is check-summed at the level of a B+ tree page, and the checksum is stored independently from the page itself. This allows us to detect all forms of disk corruption, including lost and misdirected writes and bit rot"

Thus, you must turn on checksums on data, it is not on by default. This is very strange. ReFS developers talk lots of dataintegrity and safety, and still ReFS is not checksumming everything. Apparently, the MS developers are aware of data corruption and bit rot, but does not turn on checksumming everywhere? Why is that?

My guess is that it is difficult to make a filesystem safe. It does not suffice to just checksum everything, it might still be unsafe. CERN did a study on data corruption and concluded on page 23:
http://w3.hepix.org/storage/hep_pdf/2007/Spring/kelemen-2007-HEPiX-Silent_Corruptions.pdf
"checksumming? → not necessarily enough
- end-to-end checksumming (ZFS has a point)"

Thus, it not easy to build a safe storage solution. It is like, building a safe cryptosystem, it is not easy. You can not just use a crypto and assume it is safe. No, you must design everything in the filesystem with safety in mind, and that is not easy to do. I believe that is the reason that there are no checksums everywhere in ReFS. Of course, MS can put checksums everywhere, but is is safe? At least there are research on zfs, and data corruption - and researchers conclude at zfs detects all the artificially injected errors. In a similar study, researchers concluded that ntfs, ext, xfs, jfs, etc are not safe when injecting artificial errors.

Thus, I want to see research on ReFS and data corruption before I deem it safe. Putting checksums everywhere does not make it safe. For instance, hard drives have lots of ECC checksums everywhere on the surface, and still we see unrecoverable errors on disk (according to spec sheet). Thus, checksums are not enough.



Regarding block pointer rewrite in zfs. ZFS was created by Jeff Bonwick and Matt Ahrens in 2001, both have quite Oracle. Matt Ahrens are at Delphix who are heavily involved in Illumos, the OpenSolaris kernel that is completely open. There are lot of development of ZFS in the Illumos camp. Illumos have added new zfs features that Oracle does not have. Illumos is also adding functionality so that zfs versions are backwards compatible and does not break compatibillity. Illumos have attracted several of the top Sun kernel developers, such as Bryan Cantrill (father of Dtrace) and other famous developers. It seems that zfs is most heavily developed in the Illumos camp, more than Oracle.
http://blog.delphix.com/
OpenIndiana is built on Illumos, and will utilize the latest zfs version. Also, Nexenta is built on illumos and use the latest zfs version. So for the die hard zfs fans, maybe should look at nexenta and OpenIndiana (OI)?

I think it was Matt (?) that said they might announce something on block pointer rewrite in some time, Illumos team are working on it. They have the best understanding of zfs, and are capable of implementing it.
 
ZFS is now 10 years old, and STILL they find bugs in it.

ZFS was released in 2005. It's not 2015 for a couple of years yet.

They still find bugs in EXT filesystems DRIVERS. But all 3 (ext2, ext3, ext4) are considered stable because the filesystem is stable. That's how I understand zfs. Bugs they've had to fix inthe various implementations have been bugs that caused data integrity issues on disk, but you could run an fsck style tool to fix it with no or minimal dataloss.
 
Back
Top