Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: Tux2 - evil patents sighted | Date | Tue, 03 Oct 2000 22:29:33 +0200 |
| |
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/
|  |