http://news.com.com/NetApp+files+patent+suit+against+Sun/2100-1014_3-6206194.html
I''m curious how many of those patent filings cover technologies that
they carried over from Auspex.
While it is legal for them to do so, it is a bit shady to inherit
technology (two paths; employees departing Auspex and the Auspex
bankruptcy asset buyout), file patents against that technology, and then
open suits against other companies based on (patents covering) that
technology.
(No, I''m not defending Sun in it''s apparent patent-growling,
either, it
all sucks IMO.)
Rob++
--
Internet: windsor at warthog.com __o
Life: Rob at Carrollton.Texas.USA.Earth _`\<,_
(_)/ (_)
"They couldn''t hit an elephant at this distance."
-- Major General John Sedgwick
On Wed, Sep 05, 2007 at 03:43:38PM -0500, Rob Windsor wrote:> (No, I''m not defending Sun in it''s apparent patent-growling, either, it > all sucks IMO.)In contrast to the positioning by NetApp, Sun didn''t start the patent fight. It was started by StorageTek, well prior to Sun''s acquisition of them. We inherited the in-flight fight, and I don''t think we wound up doing much with it. I agree Sun should have just formally dropped the suit, but nobody asked me. :) And before anyone asks, I don''t know any more about all of this than what''s been reported online. --Bill
About 2 years ago I was able to get a little closer to the patent litigation process, by way of giving a deposition in litigation that was filed against Sun and Apple (and has been settled). Apparently, there''s an entire sub-economy built on patent litigation among the technology players. Suits, counter-suits, counter-counter-suits, etc, are just part of every day business. And the money that gets poured down the drain! Here''s an example. During my deposition, the lawyer questioning me opened a large box, and removed 3 sets of a 500+ slide deck created by myself and Richard McDougall for seminars and tutorials on Solaris. Each set was color print on heavy, glossy paper. That represented color printing of about 1600 pages total. All so the attorney could question me about 2 of the slides. I almost fell off my chair.... /jim Rob Windsor wrote:> http://news.com.com/NetApp+files+patent+suit+against+Sun/2100-1014_3-6206194.html > > I''m curious how many of those patent filings cover technologies that > they carried over from Auspex. > > While it is legal for them to do so, it is a bit shady to inherit > technology (two paths; employees departing Auspex and the Auspex > bankruptcy asset buyout), file patents against that technology, and then > open suits against other companies based on (patents covering) that > technology. > > (No, I''m not defending Sun in it''s apparent patent-growling, either, it > all sucks IMO.) > > Rob++ >
Bill Moore <Bill.Moore at sun.com> wrote:> On Wed, Sep 05, 2007 at 03:43:38PM -0500, Rob Windsor wrote: > > (No, I''m not defending Sun in it''s apparent patent-growling, either, it > > all sucks IMO.) > > In contrast to the positioning by NetApp, Sun didn''t start the patent > fight. It was started by StorageTek, well prior to Sun''s acquisition of > them. We inherited the in-flight fight, and I don''t think we wound up > doing much with it. I agree Sun should have just formally dropped the > suit, but nobody asked me. :)If I am right that the case is because of a copy on write structure that always keeps consistent data structures on the disk. This is what I did already implement in 1990 with my wofs filesystem code. The basic description of my filesystem code is on the net since ~ 1995. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 05, 2007 at 03:43:38PM -0500, Rob Windsor wrote:> http://news.com.com/NetApp+files+patent+suit+against+Sun/2100-1014_3-6206194.html > > I''m curious how many of those patent filings cover technologies that > they carried over from Auspex. > > While it is legal for them to do so, it is a bit shady to inherit > technology (two paths; employees departing Auspex and the Auspex > bankruptcy asset buyout), file patents against that technology, and then > open suits against other companies based on (patents covering) that > technology. > > (No, I''m not defending Sun in it''s apparent patent-growling, either, it > all sucks IMO.)DISCLAIMER: I''ve not read any of those patents, nor do I intend to, nor did I have anything to do with the design or implementation of ZFS. Also, IANAL. To me ZFS is very, very similar to 4.4BSD''s Log Structured Filesystem. Both are have strong similarities to transactional databases. My token effort to blog about ZFS when it came out was, in fact, a comparison to 4.4BSD LFS. I don''t know about any patents in this area nor about their timelines, but I imagine that there''s a *lot* of prior art in the 4.4.BSD LFS history and in the transactional database literature going back several decades. Art on 4.4BSD LFS first appeared no later than June 1990, and perhaps much earlier. Transactional DB literature goes back at least to the early 80s. I.e., my uneducated guess is that there''s enough prior art to blow most any patent claims about ZFS out of the water. (You might take this to mean that ZFS is not all that original. I think that in a way that is quite so, but there''s plenty of originality in ZFS: RAID-Z [which depends on checksum trees], awesomely simple and user-friendly CLIs, etc...) Another disclaimer: I''ve no idea whether ZFS''s designers had 4.4BSD''s LFS in mind or knew about it when they came up with ZFS. Nico --
Nicolas Williams <Nicolas.Williams at sun.com> wrote:> On Wed, Sep 05, 2007 at 03:43:38PM -0500, Rob Windsor wrote: > > http://news.com.com/NetApp+files+patent+suit+against+Sun/2100-1014_3-6206194.html > > > > I''m curious how many of those patent filings cover technologies that > > they carried over from Auspex. > > > > While it is legal for them to do so, it is a bit shady to inherit > > technology (two paths; employees departing Auspex and the Auspex > > bankruptcy asset buyout), file patents against that technology, and then > > open suits against other companies based on (patents covering) that > > technology. > > > > (No, I''m not defending Sun in it''s apparent patent-growling, either, it > > all sucks IMO.) > > DISCLAIMER: I''ve not read any of those patents, nor do I intend to, nor > did I have anything to do with the design or implementation > of ZFS. Also, IANAL. > > To me ZFS is very, very similar to 4.4BSD''s Log Structured Filesystem. > Both are have strong similarities to transactional databases. >There is a difference between a log structured filesystem and a copy on write based filesystem. As I wrote before, my wofs (designed and implemented 1989-1990 for SunOS 4.0, published May 23th 1991) is copy on write based, does not need fsck and always offers a stable view on the media because it is COW. http://cdrecord.berlios.de/new/private/wofs.ps.gz If you believe this is sufficient to cancel the netapps patent because of prior art, feel free to contact me..... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
On 9/5/07, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote:> As I wrote before, my wofs (designed and implemented 1989-1990 for SunOS 4.0, > published May 23th 1991) is copy on write based, does not need fsck and always > offers a stable view on the media because it is COW.Side question: If COW is such an old concept, why haven''t there been many filesystems that have become popular that use it? ZFS, BTRFS (I think) and maybe WAFL? At least that I know of. It seems like an excellent guarantee of disk commitment, yet we''re all still fussing with journalled filesystems, filesystems that fragment, buffer lags (or whatever you might call it) etc. Just stirring the pot, seems like a reasonable question (perhaps one to take somewhere else or start a new thread...)
mike <mike503 at gmail.com> wrote:> On 9/5/07, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote: > > As I wrote before, my wofs (designed and implemented 1989-1990 for SunOS 4.0, > > published May 23th 1991) is copy on write based, does not need fsck and always > > offers a stable view on the media because it is COW. > > Side question: > > If COW is such an old concept, why haven''t there been many filesystems > that have become popular that use it? ZFS, BTRFS (I think) and maybe > WAFL? At least that I know of. It seems like an excellent guarantee of > disk commitment, yet we''re all still fussing with journalled > filesystems, filesystems that fragment, buffer lags (or whatever you > might call it) etc.Maybe people did not see that wofs uses two different concepts to allow it to be optimal for WORM media. The best documented one is the inverted meta data tree that allows wofs to write only one new generation node for one modified file while ZFS needs to also write new nodes for all directories above the file including the root directory in the fs. The other one is the fact that COW is the only way to implement a FS on a WORM media. COW allows wofs to live without fsck and always grants a conststent fs view on the medium. The inverted tree allows to write few data for modified files and to auto move the orphaned files to /lost+found during the mount process in the kenel. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
mike wrote:> On 9/5/07, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote: >> As I wrote before, my wofs (designed and implemented 1989-1990 for SunOS 4.0, >> published May 23th 1991) is copy on write based, does not need fsck and always >> offers a stable view on the media because it is COW. > > Side question: > > If COW is such an old concept, why haven''t there been many filesystems > that have become popular that use it? ZFS, BTRFS (I think) and maybe > WAFL? At least that I know of. It seems like an excellent guarantee of > disk commitment, yet we''re all still fussing with journalled > filesystems, filesystems that fragment, buffer lags (or whatever you > might call it) etc. > > Just stirring the pot, seems like a reasonable question (perhaps one > to take somewhere else or start a new thread...)I think it was due to cpu cycles and memory not being quite as cheap then as they are now. Oh, and that it''s sufficiently different from existing ideas on how to write filesystems that there wasn''t really any incentive to actually do it. "$X ain''t broke (sufficiently) so let''s not rock the boat" James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson
"James C. McPherson" <James.C.McPherson at gmail.com> wrote:> > If COW is such an old concept, why haven''t there been many filesystems > > that have become popular that use it? ZFS, BTRFS (I think) and maybe > > WAFL? At least that I know of. It seems like an excellent guarantee of > > disk commitment, yet we''re all still fussing with journalled > > filesystems, filesystems that fragment, buffer lags (or whatever you > > might call it) etc. > > > > Just stirring the pot, seems like a reasonable question (perhaps one > > to take somewhere else or start a new thread...) > > > I think it was due to cpu cycles and memory not being quite > as cheap then as they are now.CPU cycles have not been a problem. Memory was a problem and for this reason, I did implement virtual kernel memory for my wofs implementation.> Oh, and that it''s sufficiently different from existing ideas > on how to write filesystems that there wasn''t really any > incentive to actually do it.It has been implemented for SunOS-4.0 If you do not believe it, just ask Carsten Bormann (cabo at tzi.org) who did discuss the ideas with me and who did supervise my master thesis "wofs". As a side note: I did hear around 1996 that Luftansa used WORM media to archive important passenger data. They did not have something like wofs and did write tar archives only a few times per day to avoid that thousands of new small files caused to rewrite all directroy inode data upwards to the root directory. This verifies that other COW implementations exist before the netapps patent was files. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> The best documented one is the inverted meta data tree that allows wofs to write > only one new generation node for one modified file while ZFS needs to also write new > nodes for all directories above the file including the root directory in the fs.I believe you are thinking of indirect blocks, which are unrelated to the directory tree. In ZFS and most other filesystems, ancestor directories need not be modified when a file in a directory is modified. --matt
Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:> Joerg Schilling wrote: > > The best documented one is the inverted meta data tree that allows wofs to write > > only one new generation node for one modified file while ZFS needs to also write new > > nodes for all directories above the file including the root directory in the fs. > > I believe you are thinking of indirect blocks, which are unrelated to the > directory tree. In ZFS and most other filesystems, ancestor directories need > not be modified when a file in a directory is modified.Isn''t this against what I''ve read? If you write inode data to a different location than before, you need a way to tell the ancestor directory where the new data is located.>From what I''ve read so far and what I have in mind from a personal talk withJeff Bonwick in September 2004, this is done by rewriting at least parts of the ancestor directory inode. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:> Matthew Ahrens <Matthew.Ahrens at sun.com> wrote: > >> Joerg Schilling wrote: >>> The best documented one is the inverted meta data tree that allows wofs to write >>> only one new generation node for one modified file while ZFS needs to also write new >>> nodes for all directories above the file including the root directory in the fs. >> I believe you are thinking of indirect blocks, which are unrelated to the >> directory tree. In ZFS and most other filesystems, ancestor directories need >> not be modified when a file in a directory is modified. > > Isn''t this against what I''ve read? > > If you write inode data to a different location than before, you need a way to > tell the ancestor directory where the new data is located.No; directories point to the files (and directories) that they contain by object (inode) number, not by block pointer (physical disk location). When new contents are written to a file, its object (inode) number does not change.> From what I''ve read so far and what I have in mind from a personal talk with > Jeff Bonwick in September 2004, this is done by rewriting at least parts of the > ancestor directory inode.That is incorrect; you must have misunderstood Jeff. Could you point me to where you''ve read this, so that it can be corrected or clarified? --matt
On Thu, Sep 06, 2007 at 01:43:21PM -0700, Matthew Ahrens wrote:> Joerg Schilling wrote: > > Matthew Ahrens <Matthew.Ahrens at sun.com> wrote: > > > >> Joerg Schilling wrote: > >>> The best documented one is the inverted meta data tree that allows wofs to write > >>> only one new generation node for one modified file while ZFS needs to also write new > >>> nodes for all directories above the file including the root directory in the fs. > >> I believe you are thinking of indirect blocks, which are unrelated to the > >> directory tree. In ZFS and most other filesystems, ancestor directories need > >> not be modified when a file in a directory is modified. > > > > Isn''t this against what I''ve read? > > > > If you write inode data to a different location than before, you need a way to > > tell the ancestor directory where the new data is located. > > No; directories point to the files (and directories) that they contain by > object (inode) number, not by block pointer (physical disk location). When > new contents are written to a file, its object (inode) number does not change.When you modify a file ZFS writes a new block and new indirect blocks if needed and a new dnode (inode) and it updates the special file that maps dnode numbers to block pointers, which means writing a new block, possibly new indirect blocks, and a new dnode for that special file. All in one transaction. Parent directories up to / are not affected (dnodes don''t even have pointers to them, which wouldn''t be easy to do anyways given POSIX hard-link semantics). That''s what I understood. Which, BTW, is *exactly* how the 4.4BSD Log Structure Filesystem works. That is, LFS has a special file mapping inode numbers to block pointers and updates to any file involve the same approach of writing new blocks for the affected file and that special file (other details, of course, differ, such as the structure of ZFS block pointers vs. LFS'').
Thanks Jim for the entertainment. I was party to a similar mess. My father owned an operated a small Electrical Supply business that I worked at since the age of 8. I was recently pulled into a large class-action Asbestos suit against the business since I was the only one still alive through the period of interest (1960s). I was subject to a deposition in a room with 50+ lawyers and myself. The whole situation was so surreal. The questioning went something like this: Q: Did you sell lighting fixtures with wire? A: Yes Q: Did it have asbestos? A: No Q: How can you be so sure. A: I hung over 20,000 fixtures in the showroom over the years. In order to save time, I would strip the wire with my teeth. I think I''d know if they contained asbestos by now. Q: You''d do what? A: I''d strip the wire with my teeth. I can demonstrate, if you want. I was told that I had the record for a deposition in this case, lasting almost 4 hours. A month later I got the transcript and they actually changed my words! I sent back 50 pages of corrections to a 200 page document. A year later they dropped the suit. What a total waste of human effort and money. Gary> About 2 years ago I was able to get a little closer > to the patent > litigation process, > by way of giving a deposition in litigation that was > filed against Sun > and Apple > (and has been settled). > > Apparently, there''s an entire sub-economy built on > patent litigation > among the > technology players. Suits, counter-suits, > counter-counter-suits, etc, > are just > part of every day business. And the money that gets > poured down the drain! > > Here''s an example. During my deposition, the lawyer > questioning me opened > a large box, and removed 3 sets of a 500+ slide deck > created by myself and > Richard McDougall for seminars and tutorials on > Solaris. Each set was > color print on heavy, glossy paper. That represented > color printing of about > 1600 pages total. All so the attorney could question > me about 2 of the > slides. > > I almost fell off my chair.... > > /jim > > > > Rob Windsor wrote: > > > http://news.com.com/NetApp+files+patent+suit+against+S > un/2100-1014_3-6206194.html > > > > I''m curious how many of those patent filings cover > technologies that > > they carried over from Auspex. > > > > While it is legal for them to do so, it is a bit > shady to inherit > > technology (two paths; employees departing Auspex > and the Auspex > > bankruptcy asset buyout), file patents against that > technology, and then > > open suits against other companies based on > (patents covering) that > > technology. > > > > (No, I''m not defending Sun in it''s apparent > patent-growling, either, it > > all sucks IMO.) > > > > Rob++ > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ssThis message posted from opensolaris.org
> http://cdrecord.berlios.de/new/private/wofs.ps.gz > > > J?rg >Hi J?rg, This link doesn''t work. If possible, could you make it as an attachment? Thanks. This message posted from opensolaris.org
"W. Wayne Liauh" <wp at HawaiiLinux.us> wrote:> > http://cdrecord.berlios.de/new/private/wofs.ps.gz > > > > > > J?rg > > > > Hi J?rg, > > This link doesn''t work. If possible, could you make it as an attachment? Thanks.I see no reason why it should not work, it works for me. Could you give more information? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
"W. Wayne Liauh" <wp at HawaiiLinux.us> wrote:> > http://cdrecord.berlios.de/new/private/wofs.ps.gz > > > > > > J?rg > > > > Hi J?rg, > > This link doesn''t work. If possible, could you make it as an attachment? Thanks.Thanks to Tatjana, I now have a new version (decoupled from our OpenSolaris book SBN: 978-3-540-29236-4) that includes 5 more images. http://opensolaris.in-berlin.de/pdf/WoFS.pdf Or http://cdrecord.berlios.de/new/private/WoFS.pdf J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
> Thanks to Tatjana, I now have a new version > (decoupled from our > OpenSolaris book SBN: 978-3-540-29236-4) that > includes 5 more images. > > http://opensolaris.in-berlin.de/pdf/WoFS.pdf > > Or http://cdrecord.berlios.de/new/private/WoFS.pdf > > J?rg > > -- > EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg > Schilling D-13353 Berlin > js at cs.tu-berlin.de (uni) > schilling at fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ > ftp://ftp.berlios.de/pub/schily > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ssThanx, funktioniert es jetzt. This message posted from opensolaris.org