lkml.org 
[lkml]   [2000]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Tux2 - evil patents sighted
Date
Chris Good wrote:
> In article <news2mail-39D93163.343E7A9B@innominate.de>, Daniel Phillips wrote:
> >Thomas Graichen forwarded me some interesting information from the
> >freebsd-fsdevel list regarding 3 patents held by Network Appliance
>
> A couple of points:
> First their patents are very much tied into their implementation
> of WAFL, your implementation of Tux2 should be sufficiently different
> not to cause a problem.

This may well be the case, see below.

> You mentioned multi-bit maps which sounds
> like a big enough difference on its own.

Yes, thats a big difference. Here is my current list of significant
differences:

- No defree list in WAFL (see multiple bits/block below). Tux2 puts
all blocks freed or rewritten on a list for freeing later, after the
next phase change. *probably very important*

- Tux2 uses one bit per block for allocation map, WAFL uses 32.
Perhaps one reason for this is that Tux2's snapshot algorithm is
separate from its atomic commit algorithm. Perhaps combining those
two parts clouded somebody's thinking.

- Atomic updating and snapshotting are combined in WAFL, separate in
Tux2

- Different sense of WAFL's in snapshot bit:
WAFL: snapshot bit on -> block must not be flushed or modified
Tux2: inphase bit on -> block must not be flushed but *ok to modify*
Again,this is probably key.

- WAFL maintains one divergent tree in memory, Tux2 maintains two.

- WAFL has to block some file transactions while blocks are written
to disk, Tux2 doesn't.

- WAFL maintains a single filesystem root, overwriting it on each
atomic update. Tux2 keeps a group of metaroots, choosing for the
atomic update the nearest one not overwritten in the previous update.

All this suggests the algorithms are different in some fundamental
sense. ***But I have not seen the patents themselves, only the
abstracts*** If anyone has copies of these patents, would they please
be so kind as to send them to me.

> Second Netapp are a pretty nice bunch and chasing someone doing GPL
> code isn't their style.

Netapp may be great guys but they have still claimed to own something
that properly belongs to me and the rest of humanity.

> Thirdly a hell of a lot of people buying Netapp products are fans
> of linux/*BSD, I very much doubt that they're going to risk their
> bottom line.

I retract anything I may have said that might reflect negatively on
Netapp. I haven't met them, I know very little about them.

I wasn't calm yesterday. I suspected such patents might exist ever
since I first heard of WAFL last spring. When I actually saw the patent
abstracts I became angry, not angry at Netapps but at the whole barbaric
patent system. Netapps had no choice but to apply for their patent and
I have no choice but to confront it.

If they are really great guys then let them prove it by licencing their
patents for unrestricted use in GPL-compatible code. They don't have a
lot to lose: my work is superior and GPL, and directly based on work I
did in 1989. They should realize that their main patents aren't worth
much now except to lawyers, so they might as well collect some good
karma by making their licence GPL-compatible.

It was suggested to me privately that I contact Netapp and show them my
algorithm. That seems to me to be a very good idea.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.050 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site