« August 2007 | Main | October 2007 »

September 2007

September 27, 2007

Driving a Tesla Electric Sports Car is a Strange Form of Virtual Reality

This week, I got a chance to drive a Tesla electric roadster on the twisty mountain roads above Silicon Valley. All electric, lithium-ion, zero-to-sixty in less than four seconds – not that I stopped at 60. (Whee!)

The electric motor feels very different from an internal combustion engine. Much smoother. In my regular car, if I’m driving at 50 mph and then floor it, I get a jerk of acceleration right away, and then a second jerk an instant later, when it downshifts, and then a surge. In the Tesla, it was just continuous, smooth acceleration. This makes the car track wonderfully through curves. The jerks in a normal car sometimes threaten to shake loose the wheels if you hit the accelerator too much at the wrong time, but in the Tesla, the power is a smooth surge no matter how quickly you jam the accelerator.

In my regular car, if I suddenly let off the gas after accelerating hard, I get a reverse jerk as engine compression braking suddenly slows the vehicle. In the Telsa, no jerk at all. The acceleration stops, and then a gentle deceleration kicks in. An induction motor has no natural braking (no cylinders to compress), but it’s nice for the car to slow down when you lift off the accelerator, so they programmed in some regenerative braking. In a regular car, the amount of deceleration is a side effect of cylinder size, compression, gearing, and so on, but in the Tesla, they get to program in exactly what feels right. Turns out that people prefer just a bit of deceleration at high speeds, but at slower speeds, for street driving, people like more deceleration.

In a sense, driving a Tesla is like a strange form of virtual reality. The sensations I’m feeling are designed by a programmer who has full control of the mapping between accelerator pedal and torque. (In fact, one goal of the drive was to get feedback to the Tesla engineers on their firmware choices.)

Another example is creep, which is the way that cars with automatic transmissions creep forward slightly when you lift the brake. In a regular car, that’s a natural side effect of how the transmission works, but in a Tesla, they decided to maintain that same behavior for safety, so that you won’t get out of the car with it turned on. Lift the brake and it “reminds” you, by creeping, that it is still running.

I shouldn’t say virtual reality, because I was in a real car feeling real acceleration, but it has that same designed-by-a-programmer feeling that virtual reality does. At first I thought that designed reality might be a better description, but an internal combustion engine is certainly designed, and the acceleration and engine braking profile is something that designers take into account. I think the real difference is the level of direct control that you have with programming, as compared to the indirect influence you have when you design with physical materials.

What enables that feeling of programmed reality in the Tesla is the flat torque curve of their electric induction motor. Its torque is almost perfectly flat from 0 to 6000 rpm and then drops linearly to 50% torque at 11,000 rpm. An induction motor can generate full torque even at 0 rpm, and can go from no power to full power in milliseconds. By contrast, an internal combustion engine can’t generate any torque at 0 rpm (it stalls), and it delivers full torque only in a narrow range.

In order to generate programmed reality, you need a physical medium that is sufficiently malleable, like an induction motor or an LCD display, to give you full programmable control. Perhaps the real lesson here is that – given the flexibility of programmed systems – we should have a higher expectation of usability and design elegance for programmed reality. With great power comes great responsibility.

September 13, 2007

Why Run VMware Over NAS?

At VMWorld yesterday, I was surprised how excited customers are about using NFS to access VMDKs, even for virtual machines hosting Windows. (A VMDK is a VMware Virtual Disk, and it holds the boot image for its virtual machine.)

Since a VMDK is a virtual disk, I had assumed that block-based protocols like iSCSI and Fibre Channel would make more sense than NAS, so I asked several customers why they prefer NFS.

The answer is simple: Managing .vmdk files is much easier than managing LUNs. If you have 20 or 30 virtual machines, then VMFS is great for consolidating the VMDKs into a single LUN. But NAS is much easier and more scalable if you have hundreds or thousands of virtual machines.

The big advantage is that you can use all your file management tools. Group the VMDKs for Exchange servers in one folder, SQL servers in a second, virtual desktops in a third, and so on. Instead of backing up LUNs or virtual machines individually, simply backup a directory tree of VMDKs all at once. (This is much less expensive than buying a backup license for each virtual machine, and also easier to manage.) For disaster recovery, you can replicate the data for a whole group of virtual machines as a single unit.

Some people are surprised that you can use NFS for Windows virtual machines, since Windows can’t boot from NFS. This works because VMware has built NFS into ESX’s disk virtualization layer. ESX handles the NFS protocol so that the operating system doesn’t have to. This is very similar to Oracle’s recent project to build NFS support directly into their database.

I rarely find excuses to praise Chuck Hollis from EMC, but in a recent blog he said:

I think that, in the long term, we'll find high-end NAS much more friendly for high-end VMotion / DRS farms than today's SANs. And I think that NAS has the potential to offer a few benefits that we might not find in the SAN world.

Brilliant!

VMware’s Founder Helped To Inspire WAFL

At VMworld yesterday, I got to meet with Mendel Rosenblum, one of VMware’s founders. I want to share the story of how he helped inspire WAFL.

In the early days of NetApp, when we first started developing our WAFL file system, we drew inspiration from three main file systems: FFS, Episode and LFS:

The Berkeley Fast File System (FFS) was written by Kirk McKusick. I had worked on FFS at two prior companies (MIPS and Auspex), so I was very familiar with it.

The Episode File System was developed by Transarc, which spun out of the Andrew File System (AFS) project at Carnegie Mellon. One of the architects of Episode was Mike Kazar, who joined NetApp when we acquired Spinnaker.

The Log-structured File System (LFS) was developed as part of John Ousterhout’s Sprite operating system project at Berkeley.

The graduate student who actually designed and implemented LFS was Mendel Rosenblum. It took me quite a few years to figure out that this guy whose work I admired 15 years ago was the same guy who started VMware. Imagine my surprise!

Given that a VMware founder helped inspire WAFL, it seems there’s a sort of poetic justice that so many VMware customers use it for their data.

September 07, 2007

Sun Patent Team Demanded $36 Million From NetApp

Part of Jonathan’s response to our lawsuit stunned me. He simply denied our account: “First, Sun did not approach NetApps about licensing any of Sun's patents and never filed complaints against NetApps or demanded anything.” (Our name is actually NetApp, without the ‘s’, but I didn’t want to edit his quote.) 

He says Sun never “demanded anything”, but here is an e-mail from Sun’s lawyers doing exactly that. Legal language can be tricky to understand, but the translation of Sun’s letter is “You infringe our patents, so pay us $36 million.”

The part about “mapping claims onto NetApp products” is the legal way of saying “you infringe our patents”. The statement that NetApp apparently believes “the best defense is a good offense” indicates that we had something to defend against. Indeed. The phrase, “over a year and a half ago,” shows that the attack had been going on for a long time, both from StorageTek prior to the acquisition, and continuing at Sun long after the acquisition. 

It’s true that Sun lowered its price as the implications of our WAFL patents began to sink in, but it amazes me that Jonathan would simply deny that Sun ever demanded anything, and would imply (in the name of his URL) that NetApp is somehow the patent troll here.


[Note: Sun has now countersued. See Jonathan’s blog post announcing that, and my response.]

September 06, 2007

Litigoperation: Litigating While Still Cooperating (was “NetApp Sues Sun”)

Since NetApp sued Sun, our employees have been curious how this lawsuit will affect the way they do their jobs. Here is my message to them:

If your job is to cooperate with people from Sun, then keep on cooperating with them! Be nice to them. Aside from the small team whose job is to work on this lawsuit, I hope that employees can mostly ignore it.

People have asked how I can take this attitude. A lawsuit does mean that we have an important disagreement, but it does not mean we must be “at war”. Even though we disagree, Sun and NetApp can keep working together as major IT vendors to effectively support our shared customers.

Ray Noorda, once the CEO of Novell, coined the term coopetition to describe the relationship between companies that compete, but also cooperate. A great example is NetApp’s relationship with EMC. We compete with their storage products, but we partner very effectively with VMware, which EMC owns. (Diane Greene, the CEO of VMware, even recorded a video for our annual sales conference earlier this year.) We do compete with Sun, but many, many Sun servers use NetApp storage, and we have cooperated in areas like fixing customer problems and improving NFS. I remember the early days of NFS when Sun sponsored the Connectathon conference. Engineers from all the competing computer companies would come together to test their implementations of NFS. (I always thought that management would go crazy if they saw how closely the engineers were working together to find each other’s problems and help fix each other’s bugs.)

In this same spirit, companies that are litigating can still cooperate. (Litigoperation. You heard it here first.)

Part of Jonathan’s response to our lawsuit stunned me. He simply denied our account: “First, Sun did not approach NetApps about licensing any of Sun's patents and never filed complaints against NetApps or demanded anything.” Our name is really NetApp, without the ‘s’, but I didn’t want to edit the quote.

Here is an e-mail from Sun’s lawyers that refers to “claim charts mapping StorageTek/Sun patent claims onto NetApp products.” It says they had originally sent these to us “over a year and a half ago.” Do the math, and you can see that this started in the StorageTek days, but Sun continued it after the acquisition. Their proposed settlement was “a disk storage cross license in exchange for payment from NetApp to Sun of $36.548M.” At other times, Sun said it was entitled to hundreds of millions of dollars, so we are talking about very large sums of money.

On the other hand, it was no surprise for Jonathan to focus on open source, but I just don’t get it. For me, one of the most important rules of open source is that you must only give away things that belong to you. This is a lawsuit about defending our intellectual property against Sun, and against what Sun is paying their own engineers to do. It does complicate things that Sun has open sourced ZFS, but this is not a lawsuit about open source.

September 05, 2007

NetApp Sues Sun for ZFS Patent Infringement

This morning, NetApp filed an IP (intellectual property) lawsuit against Sun. It has two parts. The first is a “declaratory judgment”, asking the court to decide whether we infringe a set of patents that Sun claims we do. The second says that Sun infringes several of our patents with its ZFS technology.

How did we get here?

Like many large technology companies, Sun has been using its patent portfolio as a profit center. About 18 months ago, Sun’s lawyers contacted NetApp with a list of patents they say we infringe, and requested that we pay them lots of money. We responded in two ways. First, we closely examined their list of patents. Second, we identified the patents in our portfolio that we believe Sun infringes.

With respect to Sun’s patent claims, our lawsuit explains that we do not infringe, and – in fact – that they are not even valid. As a result, we don’t think we should be paying Sun millions of dollars.

On the flip side, our suit points out that Sun’s ZFS appears to infringe several of NetApp’s WAFL patents. It looks like ZFS was a conscious reimplementation of our WAFL filesystem, with little regard to intellectual property rights. Here’s what creators of ZFS have to say: “The file system that has come closest to our design principles, other than ZFS itself, is WAFL … the first commercial file system to use the copy-on-write tree of blocks approach to file system consistency.” One of the first patents I filed at NetApp describes this “copy-on-write tree of blocks” technique in detail.

We filed suit against Sun because after we pointed out the WAFL patents, their lawyers stopped getting back to us. The first part of our suit is a declaratory judgment. It’s complicated, but the basic idea is that Sun claims we infringe their patents, so we are requesting a trial to show that’s not true. In essence, a declaratory judgment calls their bluff. It allows us to force a legal conclusion, rather than leaving this threat hanging over our heads. The second part is a complaint against Sun for infringing several WAFL patents with ZFS.

As we file this case, I’m painfully aware of the bad feelings that many people have about IP lawsuits. Business people sometimes view them as the last gasp of a dying company, while some technical folks view them as evil under any circumstances. In this case, I doubt that business people will be too concerned, given our growth rate, profitability, and the fact that we are responding to Sun’s claims against us. I expect skeptical technical people to be harder to comfort.

This case is especially sensitive, because Sun has released ZFS as open source. It is admirable to contribute to open source. I have done it personally, although it was a long time ago that I was writing code, and NetApp has also contributed as a company. But it doesn’t help the open source movement to give away code that is encumbered with someone else’s patent rights. The sooner we determine the true status of ZFS, the better it will be for everyone. NetApp certainly doesn’t believe that we can somehow erase every copy of ZFS that has been downloaded. (Impossible!) This lawsuit isn’t about downloads for personal or non-commercial use; it is about what Sun is doing.

We could have a long debate about the merits of the patent system. (I expressed my own qualms here.) But like it or not, it’s the law of the land. Here’s an analogy. Suppose you own a pro football team, and you really believe that touch football would be safer and more humane than tackle. You can lobby all you want to try to change rules, but until you are successful, I recommend that your team keep wearing pads and helmets. NetApp is participating in attempts to reform the patent system, but meanwhile we will play by the rules as they exist.

In closing, let me say that the legal system is a method of resolving disputes between companies, but it does not mean we are “at war”. During this process, we will continue to support all Sun products, including ZFS filesystems that use NetApp storage. It is not in anyone’s interest – Sun’s or ours – to leave a bunch of customers in the lurch. I hope that Sun will respond in kind.

[Note: Sun has now countersued. See Jonathan’s blog post announcing that, and my response.]

Non-technical people can stop reading now.

It is important to me that technical readers not confuse NetApp with SCO, so in our lawsuit, we provided a starting point for people who want to dig deeper. This is not an exhaustive analysis of our case. We simply highlight one particular patent and one particular aspect of ZFS to help people see that this case of infringement is real.

Here’s how the ZFS designers describe filesystem consistency:

The best way to avoid file system corruption due to system panic or power loss is to keep the data on the disk self-consistent at all times, as WAFL does. To do so, the file system needs a simple way to transition from one consistent on-disk state to another without any window of time when the system could crash and leave the on-disk data in an inconsistent state.

In the ZFS paper, search for uberblock, and compare its role in filesystem consistency with the role of the root inode and file system information structure in our patent 5,819,292. Read claim 4 and its descendents, which describe our tree-of-blocks consistency technique. Claim 8 and its descendents describe efficient snapshot creation based on the tree-of-blocks. Some more useful references are here (see pages 7 and 8), here, and here.

We hope that this level of openness will help raise the bar on how people pursue intellectual property suits.

Let me insert the usual legal disclaimer: I’ve quoted our complaint, but beyond that, I won’t engage in any public comment on the technical details of our case while it is pending.

More Links



Subscribe to Dave's Blog

RSS 2.0
Atom
© NetApp, Inc.  |  "Safe Harbor" Statement