SCIENTIFIC-LINUX-USERS Archives

May 2015

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:
Vladimir Mosgalin <[log in to unmask]>
Reply To:
Vladimir Mosgalin <[log in to unmask]>
Date:
Thu, 7 May 2015 02:31:27 +0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (95 lines)
Hi ToddAndMargo!

 On 2015.05.05 at 23:05:36 -0700, ToddAndMargo wrote next:

> Hi Vladimir,
>
> I have look all over Intel's specs for their new SSD DC S3510
> series SSDs (older drives are harder to find):
>
> http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3510-spec.html
>
> They do not say a thing about Garbage Collection and not having to use TRIM.
> They do say "Data set management Trim command", which means they
> support TRIM.

Well, every modern SSD (or even eMMC device) supports TRIM.

I looked at review of this SSD - it's somewhat strange, unlike Intel
SSDs of previous generation it doesn't support Idle Garbage Collection.
So, indeed, TRIM support would be very useful.

Take a look at this graph
http://img.fcenter.ru/imgmat/article/SSD/Intel_DC_S3500/207103.png

You can see performance degradation right after writes (20-40% of
original performance typically - note that this is pretty heavy test,
amount of data written is twice the size of SSD). This is expected. Now,
there are drives that support Idle Time Garbage Collection. Among these,
Plextor M5 are most amazing - they restore to original performance
without even need of TRIM at all. As for the other drives, after TRIM
they restore performance. There are, however, SandForce controllers
(Intel 530 in this example), where performance not just degrades a lot
without TRIM, it doesn't restore to original values with TRIM (though,
mind you, this is pretty heavy test, in real life this isn't that
likely).

> Also: in my research, I did find mention that TRIM did not effect
> lifespan -- TRIM only affected write speed, which would slow down
> to a crawl without it.  Can you verify this?

TRIM does indirectly affects lifespan: the write speed degradation
doesn't appear out of thin air "just because you haven't TRIMMED it". It
happens because free space becomes fragmented and SSD hardly has any
free space left (in its opinion, because without TRIM the OS doesn't
report which blocks are actually free and can be reused). But data on
SSD can't be written (or, rather, erased) in small blocks, so in order
to write new data on heavy fragmented device SSD controller has to move
data (read from half-filled blocks and rearrange, writing to different
place, to free whole blocks for new data). E.g. SSD might be able to
read 4KB blocks but erase only 512KB blocks.

Because of that, when SSD is used without TRIM for a long time, this
process greatly increases amount of written data - you write 100MB, but
SSD had to rearrange data to free bigger blocks and internally had
written 300MB. This is called "write amplification" and it decreases
lifespan of SSD much quicker. Also it makes your writes slow (as seen on
graph) because at the time you think you've written 100MB SSD had to
write 3 times more.

Proper TRIM usage makes SSD aware of all the real free blocks (all free
space in your filesystem), so it doesn't have to move data anymore and
just writes new data there. It reduces write amplification coefficient -
and thus prolongs lifespan. Not that I would worry about SSD lifespan
even with huge write amplification, mind you.  IMHO performance problem
is more important.

It doesn't TRIM itself that affects write speed or lifespan, it only
aids Garbage Collection algorithms of SSD controller. Just keep in mind
that getting bad linear write performance usually means big write
amplification because SSD doesn't have much free blocks.

Alternative to TRIM-aided GC is Idle Time Garbage Collection (which you
could see on Plextor), which actively scans data in background, finds
empty blocks (zeroes) and marks them as free. Well probably more
complicated than that, but it's the idea. So given some idle time (SSD
runs this type of GC only when it isn't too busy serving user requests,
obviously), it is possible to free blocks for future writings even
without OS reporting them using TRIM.

There are other alternatives, e.g. SandForce controllers internally
compress data to write less, you can say that they might have less-than
1 write amplification coefficient. However, this doesn't help when
incompressible data is written.

I'm sorry about initial confusion suggesting that Intel DC drive works
well without TRIM; I knew that DC drives use good controller and it will
give you much better experience than SF-based drive but I didn't
check that they actually have Idle GC. Previous generations Intel drives
did, but not these. S3500 relies on TRIM for GC.


-- 

Vladimir

ATOM RSS1 RSS2