NetApp - Eisler's NFS Blog

Attending two Storage Conferences this week

This week, Connectathon and FAST are running.

Yesterday I presented an update on the NFSv4 working group at IETF at Connectathon.

Today at Connectathon, (as I type), Pranoop Erasani is presenting a description of NetApp's pNFS server for Data ONTAP. Tomorrow, I've schedule to co-present with other storage vendors (icnluding EMC, Panasas, and Sun) at the pNFS BOF at the FAST 2009 Conference.

The Connectathon presentations will be available at http://www.connectathon.org/talks09/index.html .

Information about the pNFS BOF at the FAST conference is at http://www.usenix.org/events/fast09/bofs.html#pnfs .

Chuckle for today

Bryan Cantrill of Sun made a scathing indictment of the SPEC SFS benchmark earlier this week. I infer from Bryan's post that Sun's Fishworks team will not be posting SPEC SFS numbers.

My reactions:

• Of course SPEC SFS does not model every real workload. No benchmark can model every customer's needs. Show me one million storage customers, and I'll show you one billion workloads (assuming you'll give me the storage to capture all the packet traces). You have to pick one, and start there for a basis for comparison.
• About eight years ago Brian Pawlowski made the observation to me that those who criticize the SPEC SFS benchmark and instead attempt to push their own custom benchmark methodology are those who are probably producing SPEC SFS numbers that are not good enough to publish.
• As a corollary to the above two points, if a vendor can't excel at SPEC SFS, it probably can't excel at much else. SPEC SFS performance is the minimum bar for entry into the NAS business.
• SPEC's benchmarks are a product of the efforts of the companies that contribute. From our association at Sun, I know Bryan Cantrill is a very smart guy. Last I checked, Sun was still a member of SPEC and the SFS subcommittee. I'm sure the subcommittee could use his contributions on the follow on to SPEC SFS 2008.
• On the lack of a price/performance metric in SPEC SFS. Back in 1992 when LADDIS was being worked on, I recall this was a topic of discussion. The reason why the price/performance metric was not added was because:
1. Like many industries, few storage companies have fixed pricing. As much as heads of sales departments would prefer to charge the same highest price to every customer, it isn't going to happen. Storage is a buyers' market. And for storage devices that serve NFS and now CIFS, the easily accessible numbers on spec.org are yet another tool for buyers. I just don't understand why a storage vendor would advocate removing that tool.
2. In storage, the cost of the components to build the device falls continuously. Just as our customers have a buyers' market, we storage vendors are buyers of components from our suppliers and also enjoy a buyers' market. Re-submitting numbers after a hunk of sheet metal declines in price is silly.

• On caching .... Tom Haynes made a comment that NetApp appears to agree with Bryan's assertion that because SPEC SFS does not encourage external caching, vendors do not sell external caches. Actually, for about a year now NetApp has been selling external cache appliances. And NetApp is not the only storage vendor with an external cache appliance. In Bryan's post we see that ACCESS operations were increased in the SPEC SFS 2008 workload relative to SPEC SFS 3.0. I can't seriously think that Bryan believes storage vendors want to handle more ACCESS calls. The percentage increased between 3.0 and 2008 because customers switched from NFS clients that had a good internal cache of ACCESS results to ones that did not. I.e. customers stopped using Solaris NFS clients. This was unfortunate for Sun, but believe me, it was unfortunate for NetApp too ... I'm still having nightmares from last fall's customer escalation caused by a really bad ACCESS cache on the client. But nonetheless, the philosophy of SPEC SFS has always been to model reality as opposed to the idealist reality dream where a storage device never has to process a request. P.S., in an earlier blog post, I made the argument that SPEC SFS 2008's differences from SPEC SFS 3.0, show the caching on NFS clients has improved.