Latest SPECsfs2008 results, over 1 million NFS ops/sec – chart-of-the-month

Column chart showing the top 10 NFS througput operations per second for SPECsfs2008
(SCISFS111221-001) (c) 2011 Silverton Consulting, All Rights Reserved

[We are still catching up on our charts for the past quarter but this one brings us up to date through last month]

There’s just something about a million SPECsfs2008(r) NFS throughput operations per second that kind of excites me (weird, I know).  Yes it takes over 44-nodes of Avere FXT 3500 with over 6TB of DRAM cache, 140-nodes of EMC Isilon S200 with almost 7TB of DRAM cache and 25TB of SSDs or at least 16-nodes of NetApp FAS6240 in Data ONTAP 8.1 cluster mode with 8TB of FlashCache to get to that level.

Nevertheless, a million NFS throughput operations is something worth celebrating.  It’s not often one achieves a 2X improvement in performance over a previous record.  Something significant has changed here.

The age of scale-out

We have reached a point where scaling systems out can provide linear performance improvements, at least up to a point.  For example, the EMC Isilon and NetApp FAS6240 had a close to linear speed up in performance as they added nodes indicating (to me at least) there may be more there if they just throw more storage nodes at the problem.  Although maybe they saw some drop off and didn’t wish to show the world or potentially the costs became prohibitive and they had to stop someplace.   On the other hand, Avere only benchmarked their 44-node system with their current hardware (FXT 3500), they must have figured winning the crown was enough.

However, I would like to point out that throwing just any hardware at these systems doesn’t necessary increase performance.  Previously (see my CIFS vs NFS corrected post), we had shown the linear regression for NFS throughput against spindle count and although the regression coefficient was good (~R**2 of 0.82), it wasn’t perfect. And of course we eliminated any SSDs from that prior analysis. (Probably should consider eliminating any system with more than a TB of DRAM as well – but this was before the 44-node Avere result was out).

Speaking of disk drives, the FAS6240 system nodes had 72-450GB 15Krpm disks, the Isilon nodes had 24-300GB 10Krpm disks and each Avere node had 15-600GB 7.2Krpm SAS disks.  However the Avere system also had a 4-Solaris ZFS file storage systems behind it each of which had another 22-3TB (7.2Krpm, I think) disks.  Given all that, the 16-node NetApp system, 140-node Isilon and the 44-node Avere systems had a total of 1152, 3360 and 748 disk drives respectively.   Of course, this doesn’t count the system disks for the Isilon and Avere systems nor any of the SSDs or FlashCache in the various configurations.

I would say with this round of SPECsfs2008 benchmarks scale-out NAS systems have come out.  It’s too bad that both NetApp and Avere didn’t release comparable CIFS benchmark results which would have helped in my perennial discussion on CIFS vs. NFS.

But there’s always next time.


The full SPECsfs2008 performance report went out to our newsletter subscriber’s last December.  A copy of the full report will be up on the dispatches page of our site sometime later this month (if all goes well). However, you can see our full SPECsfs2008 performance analysis now and subscribe to our free monthly newsletter to receive future reports directly by just sending us an email or using the signup form above right.

For a more extensive discussion of file and NAS storage performance covering top 30 SPECsfs2008 results and NAS storage system features and functionality, please consider purchasing our NAS Buying Guide available from SCI’s website.

As always, we welcome any suggestions on how to improve our analysis of SPECsfs2008 results or any of our other storage system performance discussions.


5 Reasons to Virtualize Storage

Storage virtualization has been out for at least 5 years now and one can see more and more vendors offering products in this space. I have written before about storage virtualization in “Virtualization: Tales from the Trenches” article and I would say little has changed since then but it’s time for a refresher.

Storage virtualization differs from file or server virtualization by focusing only on FC storage domain. Unlike server virtualization there is no need to change host operating environments to support most storage virtualization products.

As an aside, there may be some requirement for iSCSI storage virtualization but to date I haven’t seen much emphasis on this. Some of the products listed below may support iSCSI frontends for FC backend storage subsystems but I am unaware of any that can support FC or iSCSI frontend for iSCSI backend storage.

I can think of at least the following storage virtualization products – EMC Invista, FalconStor IPStor, HDS USP-V, IBM SVC, and NetApp ONTAP. There are more than just these but they have the lion’s share of installations, Most of these products offer similar capabilities:

  1. Ability to non-disruptively migrate data from one storage subsystem to another. This can be used to help ease technology obsolescence by online migrating data from an old subsystem to a new subsystem. There are some tools and/or services on the market which can help automate this process but storage virtualization trumps them all in that it can help tech refresh as well as provide other services.
  2. Ability to better support multiple storage tiers by migrating data from one storage tier to another. Non-disruptive data migration can also ease implementation of multiple storage tiers such as slow/high capacity disk, fast/low capacity disk and SSD storage within one storage environment. Some high end subsystems can do this with multiple storage tiers within one subsystems, but only storage virtualization can do this across storage subsystems.
  3. Ability to aggregate heterogeneous storage subsystems under one storage management environment. The other major characteristic of most storage virtualization products is that they support multiple vendor storage subsystems under one storage cluster. This can be very valuable in multi-vendor shops by providing a single management interface to provision and administer all storage under a single storage virtualization environment.
  4. Ability to scale out rather than just scale up storage performance. By aggregating storage subsystems into a single storage cluster one can add storage performance by simple adding more storage virtualization cluster nodes. Not every storage virtualization system supports multiple cluster nodes but those that do offer another dimension to storage subsystem performance.
  5. Ability to apply high-end functionality to low-end storage. This takes many forms not the least of which is sophisticated caching, point-in-time copies and data replication or mirroring capabilities typically found only in higher end storage subsystems. Such capabilities can be supplied to any and all storage underneath the storage virtualization environment and can make storage much easier to use effectively.

There are potential downsides to storage virtualization as well, not the least of which is lock-in but this may be somewhat of a red-herring. Most storage virtualization products make it easy to migrate storage into the virtualization environment. Some of these products also make it relatively easy to migrate storage out of their environment as well. This is more complex because data that was once on this storage could be almost anywhere in the current virtualized storage subsystems and would need to be re-constituted back in one piece on the storage being exported.

The other reason for lock-in is that the functionality provided by storage virtualization makes it harder to remove. But it would probably be more correct to say “once you virtualize storage you never want to go back”. Many customers I talk with that have had a good initial experience with storage virtualization want to do it again, whenever given the chance.