A recent discussion on the lkml examined the possibility of a Linux implementation of Sun's ZFS. It was pointed out that the file system is released under the GPL-incompatible CDDL, and that Sun has filed numerous patents to prevent ZFS from being reverse engineered. Max Yudin pointed out, "according to Jeff Bonwick's blog Sun issued 56 patents on ZFS, but I have no idea what they patented. Sorry, binary compatible ZFS reimplementation with GPL license might not be legal." David Litwin noted that he had been told by a ZFS developer to talk to Linux developers to see about getting non-GPL'd code included with the kernel. Theodore T'so replied, "that was totally useless answer from the ZFS developers. What he should have told you is to contact Sun management, since they are the only ones who can decide whether or not to release ZFS under a GPL license, and more importantly, to give a patent license for any patents they may have filed in the course of developing ZFS."

Alan Cox [interview] suggested, "the real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Compare it to what the old Sun company did with NFS, which is now a standard used everywhere." Theodore T'so added, "given that Sun has reportedly filed a huge number of patents covering ZFS and has refused to make them available for anything other than Solaris --- and there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux ---- I wouldn't bet on Sun being willing to making a patent license available to a hypothetical alternate implementation of the ZFS format for Linux." He went on to note, "of course, this is all open source. If someone wants to work on reimplementing ZFS from scratch, either in userspace or in the kernel, certainly the Linux community won't stop them. Given the patent issues Linus might not feel comfortable including it in the mainline sources without a promise from Sun that they won't sue the pants off of him and The Linux Foundation, but again, that's Sun's decision, and no one else can help you there."

From: "David R. Litwin" [email blocked]
To:  linux-kernel
Subject: ZFS with Linux: An Open Plea
Date:	Fri, 13 Apr 2007 19:18:41 -0400

Before I go on, let me appologise. I don't really know what I hope to  
accomplish, beyond trying to garner thoughts (and support?) for the topic.

Essentially: I want to use Linux and ZFS. I don't particularly care about  
licences or any of the rest of that nonsense. The code is there; it merely  
needs to be made to work with Linux. Done and done -- provided I can find  
some one to do this for me (I'd do it myself, but I haven't the foggiest  
notion how to go about such a feat).

By the way, forget about this FUSE business. I don't know why they're  
bothering: It's not real, it's slow and, in general, silly.

What are the thoughts of the Linux community?

I appologise right now for my intrusion. I am a Linux-nobody; I freely  
admit it. I haven't even subscribed to this list (so do CC me) because I  
don't want to be over-whelmed with the list's glorious posts. But, part of  
Linux is it's being a community. If a member of this community (that is, a  
user of Linux) can't ask the others their
thoughts and opinions, then the community has failed in a large respect.  
Take this letter as you will.

-- 
—A watched bread-crumb never boils.
—My hover-craft is full of eels.
—[...]and that's the he and the she of it.



From: Ignatich [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Sat, 14 Apr 2007 21:40:08 +0400

You might want to look at this discussion:
http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html

Let me quote my last letter:
The problem is not with CDDL, GPL is the problem. ATI and nVidia do 
provide binary modules with GPL "adapters", but I don't think legality 
of this approach was proven in court. I see no parties interested in 
proving that it is not legal (Intel perhaps?), but Sun is another story. 
They are not interested in ZFS port for Linux, because Solaris and Linux 
are real competitors, and if winds change may decide to take legal 
action. Also, such port can never be included in mainline for obvious 
reasons and I really want to see storage system such as ZFS as "default" 
for Linux in future. To sum all of this I see a number of possible 
solutions for this situation:

1. Sun dual licenses ZFS as GPLv2 and thus gives green light for 
ZFS-Linux port. Personally I doubt that this will happen.

2. Linux changes it's license. The chance is near zero.

3. US and EU courts clearly state that it is legal to use non-GPL kernel 
modules in Linux.

4. GPL ZFS reimplementation project is started. I prefer that way until 
1), 2) or 3) happen.

I know Sun opened most if not all ZFS related patents for OpenSolaris 
community. So I repeat questions I asked in my first mail:

1. Are those patents limited to CDDL/OpenSolaris code or can by used in 
GPL/Linux too?

2. If GPL code can't use those patented algorithms, will you please 
provide list of ZFS-related patents? RAID-Z and LZJB are most obvious 
technologies which may be patent protected.
<end>

So far I've got no response from Sun. According to Jeff Bonwick's blog 
Sun issued 56 patents on ZFS, but I have no idea what they patented. 
Sorry, binary compatible ZFS reimplementation with GPL license might not 
be legal. If you know something about this or can help to get ZFS 
related patent list please send me a mail.

Sincerely yours, Max V. Yudin



From: Nikita Danilov [email blocked]
Newsgroups: gmane.linux.kernel
Subject: Re: ZFS with Linux: An Open Plea
Date:	Sun, 15 Apr 2007 16:44:57 +0400

Ignatich writes:
 > You might want to look at this discussion:
 > http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html

Licenses involved cover file system _code_, rather than storage format
that is openly specified. Just stand up and implement driver for zfs
format from scratch under whatever license you want. This is exactly how
Linux supports "foreign" file systems (ntfs, fat, etc.).

Nikita.



From: Alan Cox [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 15:14:07 +0100

On Sun, 15 Apr 2007 16:44:57 +0400
Nikita Danilov [email blocked] wrote:

> Ignatich writes:
>  > You might want to look at this discussion:
>  > http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/027041.html
> 
> Licenses involved cover file system _code_, rather than storage format
> that is openly specified. Just stand up and implement driver for zfs
> format from scratch under whatever license you want. This is exactly how
> Linux supports "foreign" file systems (ntfs, fat, etc.).

That leaves all the patents Sun have filed to prevent anyone doing so.


        

From: "David R. Litwin" [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Sun, 15 Apr 2007 04:54:13 -0400

On 14/04/07, Neil Brown [email blocked] wrote:

It is generally expected that email conversations started on-list will
remain on-list, unless there is a special reason to take it off
list... though maybe it was an accident on your part.

It very much was. I'm not used to not being subscribed to a mailing list.

Example of odd commands?
    mkfs -j /dev/whatever
usually does me.  Admittedly it might be nice to avoid the -j, but
that doesn't seem like a bit issue.

Fair enough.

> 2: ZFS provides near-platter speeds. A hard-drive should not be
> hampered performance-wise by it's file system.

That is claimed of XFS too.

Really? I must have missed that one.... Any way, I use XFS so this news  
makes me like it even more.

Immediate backups to tape?  seems unlikely.
Or are you talking about online snapshots.  I believe LVM supports
those.  Maybe the commands there are odd...

O fine, be that way with your commands. :-) As I said, though, I'm not an  
expert. Merely a Linux-user. You know far more about this sort of thing  
than I ever shall.

> 4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some
> day....

ext4 will probably cope with that.  XFS definitely has very high
limits though I admit I don't know what they are.

XFS is also a few exobytes.

> 5: ZFS has little over-head. I don't want my file system to take up
> space; that's for the data to do.

I doubt space-overhead is a substantial differentiator between
filesystems.  All filesystems need to use space for metadata.  They
might report it in different ways.

Again, I'm simply reporting what I've heard. Well, read.

>
>   It is possible that that functionality can be
> > incorporated into Linux without trying to clone or copy ZFS.
>
>
> I don't deny this in the least. But, there's good code sitting,waiting  
> to be used. Why bother starting from scratch or trying to
> re-do what is already done?

Imagine someone wanting some cheap furniture and going to a 'garage
sale' at a light-house.  All this nice second-hand furniture, but you
can tell it won't fit in your house as it all has rounded edges...

It is a bit like that with software.  It might have great features and
functionality, but that doesn't mean it will fit.

XFS is a prime example.  It was ported to Linux by creating a fairly
substantial comparability interface so that code written for IRIX
would work in Linux.  That layer makes it a lot harder for other
people to maintain the software (I know, I've tried to understand it
and never got very far).

I've heard of the horrors of XFS's code. But, is there really that much  
work to be done to port ZFS to Linux? This is one area for which I have no  
information, as no one has tried (save the FUSEy folk) due to Lisences. To  
inform me!
- Hide quoted text -

-- 
—A watched bread-crumb never boils.
—My hover-craft is full of eels.
—[...]and that's the he and the she of it.



From: Rik van Riel [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Sun, 15 Apr 2007 20:50:25 -0400

David R. Litwin wrote:

>> 4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some
>> day....
> 
> ext4 will probably cope with that.  XFS definitely has very high
> limits though I admit I don't know what they are.
> 
> XFS is also a few exobytes.

The fsck for none of these filesystems will be able to deal with
a filesystem that big.  Unless, of course, you have a few weeks
to wait for fsck to complete.

Backup and restore are similar problems.  When part of the filesystem
is lost, you don't want to have to wait for a full restore.

Sounds simple?  Well, the hard part is figuring out exactly which
part of the filesystem you need to restore...

I don't see ZFS, ext4 or XFS addressing these issues.

IMHO chunkfs could provide a much more promising approach.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.



From: David Chinner [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Mon, 16 Apr 2007 13:07:05 +1000

On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote:
> David R. Litwin wrote:
> 
> >>4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some
> >>day....
> >
> >ext4 will probably cope with that.  XFS definitely has very high
> >limits though I admit I don't know what they are.
> >
> >XFS is also a few exobytes.
> 
> The fsck for none of these filesystems will be able to deal with
> a filesystem that big.  Unless, of course, you have a few weeks
> to wait for fsck to complete.

Which is why I want to be able to partially offline a chunk of
a filesystem and repair it while the rest is still online.....

> Backup and restore are similar problems.  When part of the filesystem
> is lost, you don't want to have to wait for a full restore.
> 
> Sounds simple?  Well, the hard part is figuring out exactly which
> part of the filesystem you need to restore...
> 
> I don't see ZFS, ext4 or XFS addressing these issues.

XFS has these sorts of issues directly in our cross-hairs.

The major scaling problem XFS has right now is to do with
how long repair/backup/restore take when you have hundreds
of terabytes of storage.

> IMHO chunkfs could provide a much more promising approach.

Agreed, that's one method of compartmentalising the problem.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group



From: Valerie Henson [email blocked]
Subject: Repair-driven file system design (was Re: ZFS with Linux: An Open Plea)
Date:	Mon, 16 Apr 2007 15:34:42 -0700

On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote:
> On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote:
>
> > IMHO chunkfs could provide a much more promising approach.
> 
> Agreed, that's one method of compartmentalising the problem.....

Agreed, the chunkfs design is only one way to implement repair-driven
file system design - designing your file system to make file system
check and repair fast and easy.  I've written a paper on this idea,
which includes some interesting projections estimating that fsck will
take 10 times as long on the 2013 equivalent of a 2006 file system,
due entirely to changes in disk hardware.  So if your server currently
takes 2 hours to fsck, an equivalent server in 2013 will take about 20
hours.  Eek!  Paper here:

http://infohost.nmt.edu/~val/review/repair.pdf

While I'm working on chunkfs, I also think that all file systems
should strive for repair-driven design.  XFS has already made big
strides in this area (multi-threading fsck for multi-disk file
systems, for example) and I'm excited to see what comes next.

-VAL



From: David Chinner [email blocked]
Subject: Re: Repair-driven file system design (was Re: ZFS with Linux: An Open Plea)
Date:	Tue, 17 Apr 2007 11:09:32 +1000

On Mon, Apr 16, 2007 at 03:34:42PM -0700, Valerie Henson wrote:
> On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote:
> > On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote:
> >
> > > IMHO chunkfs could provide a much more promising approach.
> > 
> > Agreed, that's one method of compartmentalising the problem.....
> 
> Agreed, the chunkfs design is only one way to implement repair-driven
> file system design - designing your file system to make file system
> check and repair fast and easy.  I've written a paper on this idea,
> which includes some interesting projections estimating that fsck will
> take 10 times as long on the 2013 equivalent of a 2006 file system,
> due entirely to changes in disk hardware.

That's assuming that repair doesn't get any more efficient. ;)

> So if your server currently
> takes 2 hours to fsck, an equivalent server in 2013 will take about 20
> hours.  Eek!  Paper here:
> 
> http://infohost.nmt.edu/~val/review/repair.pdf
> 
> While I'm working on chunkfs, I also think that all file systems
> should strive for repair-driven design.  XFS has already made big
> strides in this area (multi-threading fsck for multi-disk file
> systems, for example) and I'm excited to see what comes next.

Two steps forward, one step back.

We found that our original approach to multithreading doesn't always
work, and doesn't work at all for single disks. Under some test cases,
it goes *much* slower due to increased seeking of the disks.

This patch from the folk at Agami:

http://oss.sgi.com/archives/xfs/2007-01/msg00135.html

used a different threading approach to speeding up the repair
process - it basically did object path walking in separate threads
to prime the block device page cache so that when the real
repair thread needed the block it came from the blockdev cache
rather than from disk.

This sped up several phases of the repair process because of
re-reads needed in the different phases. What we found interesting
about this approach is that it showed that prefetching gave as good
or better results than simple parallelisation with a rudimentary
caching system. In most cases it was superior (lower runtime) to
the existing multithreaded xfs_repair.

However, the Agami object based prefetch does not speed up phase 3
on a single disk - like strided AG parallelism it increases disk
seeks and, as we discovered, causes lots of little backwards seeks
to occur. It also performs very poorly when there is not enough
memory to cache sufficient objects in the block dev cache (whose
size cannot be controlled). It sped things up by using prefetch to
speed up (repeated) I/O, not by using intelligent caching.....

However, this patch has been very instructive on how we could
further improve the threading of xfs_repair - intelligent prefetch
is better than simple parallelism (from the Agami patch), caching is
far better than rereading (from the SGI repair level caching) and
that prefetching complements simple parallelism on volumes that can
take advantage of it.

We've ended up combining a threaded, two phase object walking
prefetch with spatial analysis of the inode and object layouts
and integration into a smarter internal cache. This cache is now
similar to the xfs_buf cache in the kernel and uses direct I/O
so if you have enough memory you only need to read objects from
disk once.

Spatial analysis of the metadata is used to determine the relative
density of the metadata in an area of disk before we read it. Using
a density function, we determine if we want to do lots of small I/Os
or one large I/O to read the entire region in one go and then split
it up in memory. Hence as metadata density increases, the number of
I/Os decrease and we pull enough data in to (hopefully) keep the
CPUs busy.

We still walk objects, but any blocks behind where we are currently
reading go into a secondary I/O queue to be issued later. Hence we
keep moving in one direction across the disk. Once the first pass is
complete, we then do the same analysis on the secondary list and run
that I/O all in a single pass across the disk.

This is effectively a result of observing that repair is typically seek
bound and only using 2-3MB/s of the bandwidth a disk has to offer.
Where metadata density is high, we are now seeing luns max out on
bandwidth rather than being seek bound. Effectively we are hiding
latency by using more bandwidth and that is a good tradeoff to
make for a seek bound app....

The result of this is that even on single disks the reading of all
the metadata goes faster with this multithreaded prefetch model.  A
full 250GB SATA disk with a clean filesystem containing ~1.6 million
inodes is now taking less than 5 minutes to repair. A 5.5TB RAID5
volume with 30 million inodes is now taking about 4.5 minutes to
repair instead of 20 minutes. We're currently creating a
multi-hundred million inode filesystem to determine scalability to
the current bleeding edge.

One thing this makes me consider is changing the way inodes and
metadata get laid out in XFS - clumping metadata together will lead
to better scan times for repair because of the density increase.
Dualfs has already proven that this can be good for performance when
done correctly; I think it also has merit for improving repair times
substantially as well.

FWIW, I've already told Barry he's going to have to write a
white paper about all this once he's finished.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


        

From: "David R. Litwin" [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 02:54:32 -0400

On 15/04/07,  Jesper Juhl wrote:
On 14/04/07, David R. Litwin [email blocked] wrote:
> Before I go on, let me appologise. I don't really know what I hope to
> accomplish, beyond trying to garner thoughts (and support?) for the  
> topic.
>
> Essentially: I want to use Linux and ZFS. I don't particularly care about
> licences or any of the rest of that nonsense.

The license that protects the code we write is far from nonsense.

I know. In the end, this is the reason this topic is being discussed.

I suggest the first thing you do is contact the ZFS developers and
convince them to release their code under a license that's GPL
compatible, then we can start looking at a Linux port.

I began by contacting them. One of the devs there told me to contact the  
Linux devs.

> FUSE is nice for trying out new and interresting ideas in userspace -
> it has its uses.

Yes, but it is not really for the end-user. To paraphrase another, it is  
mostly academic.

> What are the thoughts of the Linux community?
>
> Can't tell you that, all I can tell you is my own oppinion.

You make up a member of the Linux community.

> I believe
> ZFS for Linux would be interresting, if not for any other reason then
> for compatibility.

For the greater glory of Linux? :-)

> I'd personally like to see it - but, settle the
> license issue first.

And we've come full circle: The liconsinc issue.

--
Jesper Juhl 
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html



--
—A watched bread-crumb never boils.
—My hover-craft is full of eels.
—[...]and that's the he and the she of it.



From: Theodore Tso [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 09:10:45 -0400

On Tue, Apr 17, 2007 at 02:54:32AM -0400, David R. Litwin wrote:
> > The license that protects the code we write is far from nonsense.
> 
> I know. In the end, this is the reason this topic is being discussed.
> 
> I suggest the first thing you do is contact the ZFS developers and
> convince them to release their code under a license that's GPL
> compatible, then we can start looking at a Linux port.
> 
> I began by contacting them. One of the devs there told me to contact the  
> Linux devs.

Well, that was totally useless answer from the ZFS developers.  What
he should have told you is to contact Sun management, since they are
the only ones who can decide whether or not to release ZFS under a GPL
license, and more importantly, to give a patent license for any
patents they may have filed in the course of developing ZFS.  This is
not anything Linux developers can help you with.

						- Ted



From: Tomasz Kłoczko [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 15:47:32 +0200 (CEST)

On Tue, 17 Apr 2007, Theodore Tso wrote:
[..]
> Well, that was totally useless answer from the ZFS developers.  What
> he should have told you is to contact Sun management, since they are
> the only ones who can decide whether or not to release ZFS under a GPL
> license, and more importantly, to give a patent license for any
> patents they may have filed in the course of developing ZFS.  This is
> not anything Linux developers can help you with.

Realy can't or don't want (?)
So who is responsible for potential changing Linux code licensing for 
allow if not incorporate CDDL code correct interraction without breaking 
some law ?
And/or what Linux can loose on follow this king changes ?
And/or why Linux code licensing can't evolve ? Seems when Linux code was 
licensed noone was thinking about case like interraction with code under 
license like CDDL so why now it can be corrected and still many people try 
to think like "anything arond Linux must evolve .. but not Linux" (?)
Why this can't be fixes ?

If in this ponit in Linux "evniroment" can't be chaged .. sorry but is it 
not kind of hipocritics ?

kloczek



From: Alan Cox [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 15:48:14 +0100

> So who is responsible for potential changing Linux code licensing for 
> allow if not incorporate CDDL code correct interraction without breaking 
> some law ?

Every single contributor, individually. Which won't happen.

The real test of whether Sun were serious about ZFS being anywhere but
Solaris is what they do to license it - they've patented everything they
can, and made the code available only under licenses incompatible with
other OS products. Their intent is quite clear, and quite sad.

Compare it to what the old Sun company did with NFS, which is now a
standard used everywhere.

If Sun want ZFS to get used all over the place in free software then I'd
have expected at the very least to see them throw out a copy of the code,
docs and patent grant in a form that could be used, even if it came with
no other assistance of any kind. Now would be a great time to do that,
but I can't see it happening, instead they'll miss the boat just as
microsoft did with Office XML (three years ago they'd have sailed it
through ISO to the sound of fanfairs)

Alan


        


From: Daniel Hazelton [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 12:22:19 -0400

On Tuesday 17 April 2007 09:47:32 Tomasz Kłoczko wrote:
> On Tue, 17 Apr 2007, Theodore Tso wrote:
> [..]
>
> > Well, that was totally useless answer from the ZFS developers.  What
> > he should have told you is to contact Sun management, since they are
> > the only ones who can decide whether or not to release ZFS under a GPL
> > license, and more importantly, to give a patent license for any
> > patents they may have filed in the course of developing ZFS.  This is
> > not anything Linux developers can help you with.
>
> Realy can't or don't want (?)

As it has been explained to you before it is "can't"

> So who is responsible for potential changing Linux code licensing for
> allow if not incorporate CDDL code correct interraction without breaking
> some law ?

If I've parsed this query correctly the answer is: Linux is licensed under the 
GPL and because a number of people that have contributed code to it can no 
longer agree to a change in the license because they have died this cannot be 
changed. That was explained quite clearly in several mails as well.

> And/or what Linux can loose on follow this king changes ?
> And/or why Linux code licensing can't evolve ? Seems when Linux code was
> licensed noone was thinking about case like interraction with code under
> license like CDDL so why now it can be corrected and still many people try
> to think like "anything arond Linux must evolve .. but not Linux" (?)

When Linux was licensed under the GPL there was only *ONE* real choice for 
licensing it. Linus released the code under the GPL and there it has 
remained, with Linus leading development. If Linux had *NOT* been released 
under the GPL it would not be as popular or as powerful as it is - and that 
is not an opinion but a statement of fact.

> Why this can't be fixes ?

See the previous statement and several previous mails in this thread. Linux is 
licensed under the GPL, it is the *only* license agreed to by everyone that 
has contributed code. If I remember the statistics, there have been something 
like 10,000 different people that have contributed code. Since each 
contributor holds the copyright on their code they are the *ONLY* people that 
could change the license on it. Anyone attempting to change the license 
without agreement from *everyone* that has contributed code to the kernel 
they are in violation of US and international copyright laws.

> If in this ponit in Linux "evniroment" can't be chaged .. sorry but is it
> not kind of hipocritics ?

Nope. You've just ignored it when it was explained *why* the existing ZFS code 
cannot be simply be ported to Linux. If you really need ZFS on linux, might I 
suggest that you port the code on your own and maintain whatever patches are 
needed to use it? As it stands ZFS *might* show up in Linux as a from-scratch 
implementation, although I stress the "might" because there are patents 
involved.

DRH

(Now please, drop the subject - IMNSHO it is never going to happen)



From: Theodore Tso [email blocked]
Subject: Re: ZFS with Linux: An Open Plea
Date:	Tue, 17 Apr 2007 13:50:55 -0400

On Tue, Apr 17, 2007 at 12:22:19PM -0400, Daniel Hazelton wrote:
> Nope. You've just ignored it when it was explained *why* the existing ZFS code 
> cannot be simply be ported to Linux. If you really need ZFS on linux, might I 
> suggest that you port the code on your own and maintain whatever patches are 
> needed to use it? As it stands ZFS *might* show up in Linux as a from-scratch 
> implementation, although I stress the "might" because there are patents 
> involved.

Given that Sun has reportedly filed a huge number of patents covering
ZFS and has refused to make them available for anything other than
Solaris --- and there are senior Sun programmers who have on record
stated that one of the reasons why Sun picked the CDDL was precisely
because it was incompatible with GPL and Sun fears Linux ---- I
wouldn't bet on Sun being willing to making a patent license available
to a hypothetical alternate implementation of the ZFS format for
Linux.

Again, this is is Sun's fault, and it's because they fear Linux, and
it may have something to do with the fact that the vast majority of
their Opteron boxes get Linux installed instead of Solaris.  The
bottom line is that people who would like ZFS need to understand that
the code is Copyright by Sun, and there are almost certainly patents
owned by Sun, and if they choose licenses that are explicitly designed
to be incompatible with Linux, we should respect Sun's deep-seated
fear of Linux, and we can continue trying to innovate around better
filesystem and LVM storage technologies, as opposed to trying to chase
the ZFS tail lights.

Of course, this is all open source.  If someone wants to work on
reimplementing ZFS from scratch, either in userspace or in the kernel,
certainly the Linux community won't stop them.  Given the patent
issues Linus might not feel comfortable including it in the mainline
sources without a promise from Sun that they won't sue the pants off
of him and The Linux Foundation, but again, that's Sun's decision, and
no one else can help you there.

						- Ted

• Archive of above thread
• KernelTrap interview with Alan Cox
• KernelTrap interview with Rik van Riel