SCIENTIFIC-LINUX-USERS Archives

September 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Mon, 3 Sep 2012 14:35:48 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
> Hmmmmmm. Never had a bad hardware RAID controller. Had several
> mechanical hard drives go bad.
>
> Anyone have an opinion(s) on SSD's in a small work group server?

We've had very good luck with SSDs (singly on workstations or spanned 
volumes on servers) as primary storage mirroring to a spanned volume of 
cheap spinning disks. Never had an SSD failure (yet), but the cheap disk 
backup is live anyway so we're not too worried.

We *do* have a schedule for replacement based on the historical write 
average on the SSDs, though. Eventually they will brick so before that 
we have to replace them and planning it ahead of time is way better than 
living in panic-replacement mode whenever they eventually die. At the 
moment it looks like workstations won't even come close to needing 
replacements before the systems are end-of-life anyway, but the servers 
are a different issue (some of them are under considerable load, and 
will probably require replacement every 2 years to be totally safe).

As for the OP's question about trim: trim is available as a mount option 
as well as a few others that limit the tiny-write problem (like the 
noatime option and putting various cache directories in tmpfs in RAM 
instead of on disk, etc.) and change the way the seek/writes are 
scheduled (default is optimized for platters, which is a deoptimization 
for SSDs). You can find a wealth of information on the net about these 
issues so I won't bore you with the details here.

ATOM RSS1 RSS2