[kwlug-disc] [OT] linux server power

[L.D. Paniak]

On Mon, 2011-01-31 at 10:36 -0500, John Van Ostrand wrote:
> ----- Original Message -----
> > No offense, but this is *scary*? Where did you find such
> > misinformation?
> > SSDs are in every way faster than HDD: faster seek times, faster
> > throughput. I can't think of any reason why using an SSD would make
> > VoIP performance suffer over an HDD.
> 
> SSD performance depends on a few factors and SSDs can be slower in re-write speeds. On certain workloads the slower re-writes can offset the read gains of SSDs. 
> 
> When overwriting blocks on an SSD the block must first be erased so essentially a re-write is a read-erase-write process. Additionally SSDs store information in blocks larger than 512 bytes (4 KiB I think.) And so a file system that is not perfectly aligned to the 4 KB will require two read-erase-write operations.
> 
> Conventionally disks have had no way of knowing if a block is still in use because disk drivers don't understand file systems and file systems haven't expected disks to care. TRIM is a way to correct that and tell the drive that a block is unused so it can be erased at it's leisure removing the "erase" step when writing to unallocated, but previously used blocks.
> 
> Is there an implementation for TRIM in linux now? That would increase performance.
> 


This isn't the first time I've heard cautionary tones regarding SSD and
VoIP from people that I'd otherwise completely agree with on IT matters.
The re-write issue described by John certainly exists, but in VoIP
systems with SSDs that I have dealt with in the past year, I have not
seen a negative impact on performance.  VoIP systems hardly ever go to
disk anyway during real-time (phone call) transactions.  Only for
voicemail, maybe conferences?

I'm thinking that in the first iteration of SSDs (real SATA SSDs - not
flash sticks/cards) when inexpensive SSDs with JMicron controllers had a
severe "stutter" problem on random writes with 0.5s latency, people got
burned.  The bad memories linger and have been passed on as "common
knowledge".  This is only a problem with current devices if you think
160MB/s on random 4K writes is slow.

TRIM is standard issue in the Linux kernel since 2.6.33. On the other
hand, I've been abusing (fill, delete half the files, fill, delete..) my
128GB OCZ Agility on Lucid for 3/2 years now without any obvious
performance drop.  It has firmware with onboard garbage collection (GC)
which I believe keeps it relatively fresh.


I'll leave alignment issues to others:

http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

(and links therein)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20110131/94c0ae64/attachment.sig>