Solid State Disks

[Bryan J. Smith]

Define "SSD"?  That's like saying "3D."
There are different technologies, different functions, different everything.

Commodity NAND EEPROM "Flash" is one thing.  Every cell has errors
from the factory.  The wear-leveling is ignorant of the application.  There
can be countless details that you cannot affect.  They cannot be used to
take advantage of filesystems designed specifically for wear-limited cells
(like JFFS2).

However, it's typically acceptable to use Commodity NAND EEPROM
for / (and separate /boot) and /usr Ext3/4 (with journaling disabled), because
they are largely static.  One should put /tmp, /var and swap elsewhere, or
at least make /tmp and /var (what doesn't have to be persistent) as tmpfs.

The age-old concept of strict separation of static binaries, fluid data
and high changover temporary files in POSIX-like systems make even
commodity NAND EEPROM "feasible" for such solutions.**

-- Bryan

**SIDE NOTE:  It is also a great, continuing and supporting argument about
why separation of those three (3) types of stores are key, and platforms like
Windows ignorant and problematic.  Yes, I literally had this argument with
core Microsoft architects and common IT analysts back in the early '90s.
The idea of putting data and temporary stores with static files didn't seem to
be a problem with them, and POSIX-like approaches were useless in their
view.




----- Original Message ----
From: Randall C Grimshaw <rgrimsha at syr.edu>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Sent: Thu, July 1, 2010 3:38:29 PM
Subject: Solid State Disks

I think it may be time to ask: Has anyone tried using the SSD 's in a high volume production DHCP (and/or DNS) server? Do the have the speed, reliability, and other features as advertised? Can these be switched to lock read-only like a 'live-OS' CD?