A recent discussion on the lkml [1] examined the possibility of a Linux implementation of Sun's ZFS [2]. It was pointed out that the file system is released under the GPL-incompatible [3] CDDL [4], and that Sun has filed numerous patents to prevent ZFS from being reverse engineered. Max Yudin pointed out, "according to Jeff Bonwick's blog [5] 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 [6]] 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 [7] 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 [8] 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 [9] [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 [10] > > 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 [11] [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 [12] 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 [13] > > 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 [14] 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 [15] Plain text mails only, please http://www.expita.com/nomime.html [16] -- —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 [17] [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
Related Links:
- Archive of above thread [18]
- KernelTrap interview with Alan Cox [19]
- KernelTrap interview with Rik van Riel [20]