Does anyone here use Solid State Hard Drives?

Do they perform as well as suggested

[inbound]

I'm looking at solid state discs as an option for storing around 15GB of data that will only change on a monthly build cycle. I know it could be done in memory but that seems to be a lot of hassle once you get into multi GB storage requirements (and I'm not exactly a server guru).

I'd like to know if anyone out there uses SSD (RAM based with battery backup) or FSSD (flash based - but slower read/write). Any good/bad experiences will help us decide what to research further.

Our data is fairly simplistic and may even be suitable for storing in the SSD filesystem, using flat files, depending on how it is processed (~15 Million ~1K files). Each query will simply retrieve up to 27 of these files so access speed is more important than transfer rate (hence FSSD is under consideration - due to cost). The number of queries per second would be low , our main concern is getting the data out for processing as fast as possible.

My understanding is that SSD can handle 10,000 i/o p/s if the file size is just 1K. In theory this would allow us to retrieve 27 1K files in in under 1/300th of a second - which is well below the 1/50th of a second that would be acceptable (don't ask why it needs to be that fast -it's a long story).

Thanks for getting this far, any help would be appreciated (even if it's to tell me that a well configured MySQL / PostgreSQL box will do it at a fraction of the cost).

[lammert]

I am using solid state disks for various systems since 1996. Some old ones with only 1MB of battery backed SRAM and 1MB of EEPROM are still running. My main usage is in remote systems or systems in harsh environments and these systems tend not to need much performance, so I cannot comment too much on that.

One remark however on FSSD systems I have encountered as important is the number of write cycles. The main reason FSSD systems fail is the detoriation that occurs during the write proces. Older and cheaper systems often allow only a few number of rewrites per block. This can be as low as 50, where modern new FSSD chips allow 10,000 or more rewrites per block. After you have reached that number, bits will randomly start to fail. You might not notice that first, but it will happen.

Some hints:

• Don't use the FSSD system to store temporary data. Even a counter or logfile on the disk that is updated every minute or so might cause your disk to fail within months because a single block is rewritten every time.
• Look for a system with automatic wear level protection. Simple FSSD systems like the compact flash cards used in photocameras write the data to the block the operating system specifies. More sophisticated FSSD systems keep counters for every block of data which stores the number of times a block has been rewritten. When a block is rewritten many times, the firmware in the FSSD swaps the data in that block with a lesser used block. This process is completely transparent for the higher level operating system. A lookup table is used to translate the blocks specified by the operating system to a physical blocks in the FSSD chip.
• Look in the specs for the allowed number of rewrites per block. If it is not specified (as with many compact flash cards for example) assume a low number and do not buy the FSSD system, unless you expect less than 100 rewrites during your system lifetime
• You may want to switch the "update access time" of your operating system off, or in the ideal situation mount the flash system as read-only to prevent blocks to detoriate because the OS want to update the access date every time a file is accessed.