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 429325
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: brtfs
by phoenix on Wed 9th Jun 2010 23:00 UTC in reply to "RE[4]: brtfs"
phoenix
Member since:
2005-07-11

Duh (again). Btrfs does pool storage from day 1. Just because the command line tool doesn't autodetect where the pool storage is it doesn't mean it isn't there.


Hrm, so how does one take 6 harddrives, configure them as a storage pool, and then create 6 filesystems on top? From what I've read about btrfs, this isn't possible as two separate operations. Everytime you create a filesystem, you tell it which disks to use, and what RAID level to use.

By the way, ZFS didn't exist 10 years ago.


Hrm, yeah, got my dates wrong, off by 1 year. ZFS originated in October 2001 (http://blogs.sun.com/bonwick/entry/zfs_the_last_word_in) and was integrated into Solaris 10 in October 2005.

And Btrfs is 3 years old


While it's made a lot of progress in those three years, it's still far from being a ZFS replacement. Which is the point. Everyone is claiming that BtrFS (right now) is a drop-in replacement for ZFS (right now), and that there's no point in porting ZFS (or any other FS) for that reason. Doesn't matter that (right now) BtrFS is not a drop-in replacement, since it will be in a few years.

Convincing people to stop work on a competing product, because your incomplete product will blow it away when it's finished, but that could take a few more years, is the definition of what term in computing???

Reply Parent Score: 2

RE[6]: brtfs
by diegocg on Thu 10th Jun 2010 00:05 in reply to "RE[5]: brtfs"
diegocg Member since:
2005-07-08

Everytime you create a filesystem, you tell it which disks to use, and what RAID level to use.

Everytime you want to create a fs you use "btrfs subvolume create <parameters>" and btrfs will create the fs from the pool.

and that there's no point in porting ZFS (or any other FS) for that reason.

There is no point in porting ZFS because, among other things, ZFS is not just a FS, but a complete IO stack, and I doubt very much the linux developers will accept a filesystem that does not use the Linux block layer.

Reply Parent Score: 2

RE[7]: brtfs
by phoenix on Thu 10th Jun 2010 01:51 in reply to "RE[6]: brtfs"
phoenix Member since:
2005-07-11

There is no point in porting ZFS because, among other things, ZFS is not just a FS, but a complete IO stack, and I doubt very much the linux developers will accept a filesystem that does not use the Linux block layer.


There's nothing that stop it from using the Linux block layer. ZFS just needs access to a block device, whether it be via iSCSI, AoE, local, or a pseudo-block device via a file.

The FreeBSD port still uses the GEOM storage framework. And it's because of GEOM that you can add a lot of nifty features to ZFS (HAST, encryption, labelling, etc).

Linux doesn't have as nice of a storage stack as FreeBSD's GEOM, though, so it might be more difficult to port to. But ZFS just needs access to block devices, and then it manages those block devices for you.

Reply Parent Score: 2