Plastic Dino

FreeNAS 10 Impacted by the Jurassic Park Effect

In the news today is the revelation that iX, the makers of FreeNAS, had to pull FreeNAS 10, also known as FreeNAS Coral, off of the market a month after it was first released due to widespread stability issues.  This is a rather epic failure for the FreeNAS project that was already dramatically behind in their underlying code base and has been taking heat for this for quite some time.  What is important here is that the underlying system on which FreeNAS is based, FreeBSD, does not share the instabilities that FreeNAS has.  The problems that FreeNAS are facing are ones introduced by the extra, and unnecessary, FreeNAS layer on top of FreeBSD.

As discussed in my 2015 paper The Jurassic Park Effect there are dangers when you start tacking on third party products on top of your enterprise platforms, especially when we are talking about storage where stability matters more than anything.  Adding additional software increases risk in several vectors.  It means more code to maintain, more things to go wrong and more surface to attack.

In FreeNAS’ case, the extra layers of code are critical to the system working.  They are not ancillary code bits that have little chance of impacting the production system like would be common with a small utility, but represent the total interface of the system and completely control of all functions.  Any problems with the FreeNAS interface can turn into stability problems for the FreeBSD platform under the hood.

At the best of times we do not normally want to run a GUI on top of our servers, let alone our storage servers.  And that is if we assume that the GUI is an enterprise one that is integrated by the OEM platform vendor and gets enterprise level support and integration like you might get from Gnome 3 on RHEL or KDE on SLES.  But with FreeNAS the GUI that we work with is a small time third party add on product that is not included with, supported by or, most importantly, tested by the FreeBSD team.  The resources available to projects such as FreeNAS are fractional compared to those of enterprise operating systems.  And the scale of public beta testing is minuscule as well.  Any risk existing in FreeBSD is not addressed by this extra layer, so any risk introduced by FreeNAS itself is additional and compounded with the previously existing risk.  This risk is unnecessary as FreeNAS does not add new features or functionality, only overhead and risk.

In most cases this additional risk is not an issue, or at least we do not realize it.  But risk is always a problem, that is the nature of risk.  In the latest release however, FreeNAS’ risk proved to be more than “background noise” and has proven to be so significant that the product had to be recalled and demoted from a production release to a testing one.  Rarely does any product have to go through such a recall and demotion.  This is a blow to FreeNAS in many ways.

This demotion is a very public humiliation for FreeNAS, as a storage product it depends on a reputation of stability and reliability.  It hits both at the product itself as well as at the processes for testing that FreeNAS have used.  This will likely highlight for many potential users that there are concerns around having small, unnecessary critical path components in the “reliability chain” in such a dangerous way.  Users of FreeNAS are currently forced to either remain on a known unstable platform, or move backwards to a quite old platform that would be unnecessary if using FreeBSD directly.


What Is the SAM-SD

The SAM-SD, short for the Scott Alan Miller Storage Device*, is an approach to open storage design using enterprise hardware and software to produce high quality and highly flexible storage options for both the SMB as well as the enterprise market.

The SAM-SD is not a product per se but rather an approach. And not a new approach but a tried and true enterprise approach, the same approaches used to tackle file serving for decades and the same approaches used for other server side applications and needs. But doing so in a focused and targeted way. Storage often gets treated as unique and confusion is common, often with opponents referring to standard enterprise server builds as “DIY” in order to discredit the concept – even though this would discredit all servers anywhere.

So what does it take to be a SAM-SD?

  • A dedicated storage server or device as the intended result. (File Server / NAS / SAN / DAS / Object Storage)
  • Enterprise class hardware, the same as you would use for any enterprise class server.
  • Enterprise Open Storage software and OS, no proprietary software or closed systems that you do not control.
  • Commodity design.

*No, SAM himself did not name the device!

HP Proliant DL585 G2

Where the SAM-SD Concept Originated

The SAM-SD concept, the idea of enterprise class open storage, really started for me when working on Wall Street around late 2006 when faced with the need to provide large scale, high performance network filesystem storage to a massive compute cluster, and we found that nothing currently on the market was meeting our needs.

Read More
HP Proliant DL185 G5

The SAM-SD Model 1

The first real SAM-SD, the one famous for acquiring the name, was nothing but a specification, originally presented in Manhattan at a meeting of the SpiceCorps NYC user group where I presented on the topic of “open storage” and provided an example spec for building a practical, real world storage device.

Read More