Happy New Year to FileMaker developers and users around the world. We have a lot of work to do in the FileMaker World in 2012, and I am eager to get started.

A very key element and requirement for the reliable and safe deployment of FileMaker Pro files is, of course, FileMaker Server. And, of all the components of a FileMaker Server deployment, none is more important, I would assert, than the quality of the hard disk drive subsystem on the server machine. In 2011 we saw a lot of discussion about Solid State Drives (SSD’s) and their use with FileMaker Server. Almost all this discussion focused on the benefits of using these drives in lieu of the more traditional block I/O hard disk drives (HDD’s). Very little attention was paid to some important nuances that should inform any decision to use SSD’s. These drives are becoming more and more prevalent, and they can offer significant advantages. However, we need a fuller picture of them. I hope this BLOG post will engender some discussion in the community about SSD’s and their use in FileMaker Server machines.

An important concept of any engineering process is to focus on stress points and potential failures. Civil engineers building a bridge do this; electrical engineers designing and constructing transformers and power grids do the same. And as developers and IT Administrators dealing with FileMaker Server hardware, we must also consider stress and failure points.

In this BLOG posting, I want to highlight several considerations you should be aware of when contemplating the use of SSD’s.

SSD’s are not new devices. Their origins are in the 1950’s era. The first modern type SSD appeared 35 years ago this year. Comparing SSD’s with the traditional HHD’s can be difficult. In the late Spring of 2011 the Storage Networking Industry Association (SNIA) released two sets of specifications that can be used to measure SSD performance. Traditionally HDD benchmarks have tended to focus on aspects of those drives that are weak, particularly rotational latency and seek time. Since SSD’s don’t spin or seek, by comparison they seem superior to HDD’s.

But the equation isn’t that simple. SSD’s slow down after initial use once data have been written to them. The drive’s processor begins to move data around in the read-modify-erase-write cycle. The availability of free programmable blocks significantly impacts SSD write performance. Fewer blocks translate to diminished performance levels. Once the drive has data of any significant amounts, the NAND[1] flash memory at the drive’s core requires that old data be marked for deletion and then actually deleted in the “garbage collection” process.

A further refinement of this behavior has been described:[2]

SSDs have challenges with mixed reads and writes, and their performance may degrade over time. SSD testing must start from the (in use) full disk, as the new and empty (fresh out of the box) disk may have much better write performance than it would show after only weeks of use. [emphasis supplied]

SSD reliability and longevity are also influenced considerably by a process known as Write Amplification. This process has been described[3] as:

…an undesirable phenomenon associated with flash memory and solid-state drives (SSDs). Because flash memory must be erased before it can be rewritten, the process to perform these operations results in moving (or rewriting) user data and metadata more than once. This multiplying effect increases the number of writes required over the life of the SSD which shortens the time it can reliably operate.

All of which raises another interesting item. NAND flash memory cannot be overwritten. This can cause problems for software encryption programs. The encryption program cannot effectively deal with the data marked for deletion. Hardware based encryption programs do not have this problem.

SSD’s offer one instance of “…you get what you pay for…” at least in one respect. Entry grade and lower cost SSD’s have write speeds significantly lower than their read speeds. This is different than traditional HHD’s where read and write speeds are more nearly equal to one another; write is only marginally slower than read. Higher performing–and thus more expensive–SSD’s have a more balanced read and write speed comparison.

FileMaker Server, even in a modestly busy environment, does a lot of read and write between disk and cache as it sends data, receives data, encrypts data, and resolves calculations between client workstations and the server. Thus FileMaker Pro developers and IT Administrators will want to consider the read-write characteristics of SSD’s very carefully when selecting server hardware.

Developers and Administrators must also consider the Operating System running the server when selecting HHD or SSD type drives. Versions of Windows OS prior to Windows 7 are optimized for HHD’s, not SSD’s. Windows 7 is optimized for both SSD’s and HHD’s, and the OS operates differently if it detects the presence of a SSD, including disabling disk fragmentation. Windows Server 2008R2 supports SSD’s as well. Macintosh OS X 10.6.8 and 10.7 also support SSD’s. All of these very modern OS support the TRIM function as well, a feature needed to reduce garbage collection of data the OS has already determined to be no longer valid. This saves unnecessary wear and tear on the SSD.

These documents were a principal resource for preparing this BLOG entry, and I recommend a further reading:

http://en.wikipedia....lid-state_drive

http://www.macworld....ssdtesting.html

http://en.wikipedia....e_amplification

Benchmarking Enterprise SSD’s

http://www.stec-inc....rprise_SSDs.pdf

Notes:

[1] Not AND (NAND) electronic logic gate. http://wiki.answers....t_is_NAND_flash

[2] Benchmarking Enterprise SSD’s

http://www.stec-inc....rprise_SSDs.pdf

and see also http://en.wikipedia....lid-state_drive at Page 1.

[3] Write Amplification. http://en.wikipedia....e_amplification