Oracle Could Still Make ZFS A First-Class Upstream Linux File-System

[vsteel]

Is ZFS really that much better than current Linux file systems? I know it has been around a long time but wondering if it really has that much of an advantage anymore especially if other programs are used in conjunction with current Linux files systems (MDADM, etc...)

[Ophidian]

Lot of people miss that the tux2 file system disappeared due to NetApp aggression.

I definitely didn't know this. I just remembered a lot of talk about tux2 and then nothing

[shmerl]

Google should buy Oracle and open source everything Oracle have. End of story.

[nils_]

Google should buy Oracle and open source everything Oracle have. End of story.

Where is the profit in that?

[gigaplex]

The answer is not being in court with NetApp.

http://en.swpat.org/wiki/NetApp%27s_filesystem_patents

The troublesome patents with ZFS are mentioned above.
5,819,292 - purportedly relating to "copy on write << end of life dead.
5,963,962 "Write anywhere file-system layout" << end of life dead
6,038,570 "Method for allocating files in a file system integrated with a RAID disk sub-system" <<end of life dead.
7,174,352 - purportedly relating to "snapshot" << end of life dead.

6,857,001 - purportedly relating to "writable snapshots" << has not paid fees. Absolutely sure dead in 2022.

https://www.uspto.gov/patents-maintaining-patent/maintain-your-patent#Reinstate%20an%20expired%20patent

Yes patents read expired but due to USA patent office rules a expired patent due to not paying fees can be reversed by paying fees.

I would say the reason for CDDLv1 has reduced. A read only version of ZFS should be doable and a version where the snapshots are not writeable as well without crossing over the patent. So its still 4-5 years until everything about core ZFS is out from under the NetApp patents completely. Of course its Oracle legal department who could decide to ignore the unpaid patent if they believe if it paid they can defend ZFS from it.

Btrfs is implemented using methods that none of NetApp patents apply.

Lot of people miss that the tux2 file system disappeared due to NetApp aggression.

NetApp sees Linux kernel getting working file system like ZFS as end to a lot of their products so is likely to fight tooth and nail against it.

How does being GPL/Linux incompatible affect any of that? If ZFS violates the patents, they're already vulnerable to lawsuits.

[Cyber Killer]

Is ZFS really that much better than current Linux file systems? I know it has been around a long time but wondering if it really has that much of an advantage anymore especially if other programs are used in conjunction with current Linux files systems (MDADM, etc...)

It's usually about the feature set, that is not yet ready in BTRFS. Things like compression & dedup & sending small snapshots over network to another host (async synchronization) are killer features of ZFS. These are great for stuff like big data storage, offsite disaster recovery and other so called 'business continuity' plans that companies care greatly about (it's part of some ISO certification). IMO once this is ready & stable in BTRFS barely anybody will care about ZFS any more.

[nils_]

Is ZFS really that much better than current Linux file systems? I know it has been around a long time but wondering if it really has that much of an advantage anymore especially if other programs are used in conjunction with current Linux files systems (MDADM, etc...)

There are a few severe advantages compared to software/hardware RAID solutions (MDADM etc.). Since ZFS is aware of the data on-disk it can make better decisions on how and where to store it. This eliminates things like having to sync full drives block-by-block, the RAID-5/6 write-hole, it allows for smarter caching (SSD Cache for example), deduplication as well as compression and potentially encryption. Snapshots are also extremely cheap compared to block-level snapshots since copy on write is baked into the FS.

[omgold]

Is ZFS really that much better than current Linux file systems? I know it has been around a long time but wondering if it really has that much of an advantage anymore especially if other programs are used in conjunction with current Linux files systems (MDADM, etc...)

There are quite a couple of differences. Both have their advantages and disadvantages.

ZFS:
+ stable RAID5/6/7 (recovery, automatic disk failing, degraded operation)
+ recursive snapshots
+ integrated caching on fast disks (SSDs)
+ online deduplication
+ user/group quota
- weird performance characteristic, especially with higher RAID levels (heavy fragmentation, only full-stripe writes, hundreds of arcane parameters which need lots of tuning)
- doing everything differently from Linux conventions (weird cmdline utility syntax, ARC instead of normal page cache, no udev device discovery)

BTRFS:
+ shrinking of volumes possible
+ offline fsck (not yet reliable, I know)
+ (potentially) mixed RAID levels in same FS
- still needs more bug testing
- still needs more performance optimization work

[Guest]

Pushing ZFS upstream is the right thing to do. Of course after relicensing it to GPL-2. It's good news slowlaris is officially dead and Larry Ellison turned out to be lying bitch.

[pavlerson]

Meanwhile, ZFS works by implement its own stuff.
That helps making the code cross-portable, but that means that lots of features in ZoL are duplicate of facilities already present in the kernel.

That why a lot of kernel dev where speaking about layer violations about ZFS, but not complaining that much with BTRFS.

If you read the layer violations debate between Linux kernel devs and Jeff Bonwick (one of ZFS creators) the Linux kernel devs criticize ZFS not having enough clear layer separation. Not code duplication. ZFS does not many layers, which is a bad thing - says Linux kernel devs. Traditionally, you dont want a big monolithic code base, because that can mess the code up with stricly coupled code. That is why micro kernels such as L4 is cleaner than normal monolithic kernels such as Linux - because L4 has very clean separation between micro kernel and kernel services. Clean separation is what coders want because it helps in getting a good structure of the code. ZFS does not have a clean separation of layers, which is normally frowned upon by coders. That is why Linux kernel devs criticized ZFS. They wanted a clear separation between filesystem, LVM, raid, etc etc. Because that gives cleaner code. Normally.

However, ZFS collapses several layers and that is why ZFS can perform its magic is safer than other filesystems. Because ZFS has control of all layers it knows much about the data and can do stuff that normal filesystems can not. Normal filesystems discard information when data passes through layer to layer. ZFS does not, and keeps all information about the data. This makes the codebase monolithic, and uglier. Fortunately, ZFS is very well structured and has much less code than having several layers. Each layer needs to duplicate basic stuff, error checking, etc. One benchmark showed that ZFS was... like 50 kLoc and ext3 was like 150 kLoc - I can not remember the exact numbers. Ext3 had several layers, each using many kLoc.

So the entire discussion was that ZFS was bound to have ugly and hard to understand code, because it lacked clear separation. It was not about ZFS duplicating code. Actually, ZFS does much different from Linux, it is not duplicating code. That is why Linux needs to develop a middle layer that transforms between Solaris functionality and Linux functionality.

So you are wrong. Go and read the discussions between Jeff Bonwick and Linux kernel devs. Google "Rampant Layering Violation".

Regarding BTRFS, it tries to mimic ZFS in many ways, having a monolithic code base, etc. But BTRFS is a big failure. Many years after, BTRFS is still not stable. You can build a rocket and send people to the moon in less time.