Linked by Thom Holwerda on Mon 7th Jun 2010 10:15 UTC, submitted by kragil
Linux Employees of Lawrence Livermore National Laboratory have ported Sun's/Oracle's ZFS natively to Linux. Linux already had a ZFS port in userspace via FUSE, since license incompatibilities between the CDDL and GPL prevent ZFS from becoming part of the Linux kernel. This project solves the licensing issue by distributing ZFS as a separate kernel module users will have to download and build for themselves.
Thread beginning with comment 428830
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: brtfs
by Kebabbert on Tue 8th Jun 2010 10:29 UTC in reply to "RE[3]: brtfs"
Kebabbert
Member since:
2007-07-27

Say "enterprise" ONE MORE TIME! I dare you!

Enter... Enterpr... Hm. No, I dont dare to say the Enterprise word again, because then you might get angry. And I dont want to make you angry for saying Enterprise.


btrfs will succeed exactly because it isn't "enterprise". The software is evolved naturally,..

Just like the horrible broken mess that Linux sound API is? If that is the case, then BTRFS will never succeed.


And yes, many btrfs developers have a long experience working with file systems.

Yes, but not Enterprise experience. Oops, now I used that word again. Sorry for that.

Look. Let me explain some things to you, my young padawan learner. As someone explained: "A filesystem is far more sensitive than a kernel. If the kernel crashes, you will loose a couple of hours of work. If the filesystem crashes you loose several years of work. The filesystem is the nervous system, the skeleton of the OS. If that is bad, the rest sucks"



To get the filesystem bug free is very important. Everyone (including the Linux kernel hackers) agrees that Linux kernel is full of bugs and a mess. This approach can work on a kernel. But for a file system, it will not work. Then it has to be good coded and well designed. Which ext3, JFS, reiserfs, etc are not. You want proof?



This bad design shows up in Linux filesystem's abilities to detect and correct errors: they all suck badly. They can not even detect nor correct basic errors. Whereas ZFS detects and corrects everything. To do this well, takes lots of experience from Enterprise file systems. Those BTRFS amateur filesystem developers, know nothing about this problem "silent corruption". It is only faced in large Enterprise storage halls, just like Sun have vast experience from.

You can not just add some checksums here and there, and expect everything to be well. No, the filesystem must be built from the ground up, with respect to detect and correct all errors. This is EXTREMELY difficult to do well. If not careful, there are always errors you can not detect, if you just use a naive approach. For instance, raid-5, raid-6, ext3, jfs, reiserfs, etc - can not handle all kind of errors. Computer scientists have done research on this and proved it. They also tried to stress ZFS too, but ZFS detected every artificial error, and could have repaired all errors if the scientists had used raid. In the experiment, they ran ZFS on a single disc, so ZFS could not correct every error, but it detected them. Linux didnt even detect the errors, how can Linux then correct them? Impossible. You want proof and research papers on this?

Let me say this again. BTRFS is a cheap ZFS wannabe. It is not designed as well as ZFS. It has no focus on data integrity and silent corruption. It has nothing, just basic ZFS functionality. With Linux unstructured approach, BTRFS will not be stable. As usual, the code will be rewritten all the time, introducing new bugs. BTRFS will never catch up on ZFS. Do you really expect ZFS to stand still, and paus development? No. Instead of copying ZFS, why dont Linux guys try to make a new cool tech, instead of copying Solaris all the time? DTrace copies exist, but they are as bad as BTRFS is to ZFS. Every OS wants Solaris tech like DTrace, ZFS, etc.


btrfs is ZFS done right. [q]btrfs is to ZFS as Linux is to Solaris.

If that is the case, then there are no worries. Because then BTRFS will be buggy and bloated and scale bad. Good to hear.

Reply Parent Score: 4

RE[5]: brtfs
by Lennie on Sat 12th Jun 2010 23:42 in reply to "RE[4]: brtfs"
Lennie Member since:
2007-09-22

I wasn't saying it would catch-up, I was saying a stable filesystem, something people can rely on in a production environment as much as ext3 of ext4, but with more checksums.

Maybe not in as many places as ZFS yet, but it will be something which can be maintained by the same people that build the rest of kernel. And it can be distributed normally together with the rest of the kernel.

Reply Parent Score: 2