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:
ToddAndMargo <[log in to unmask]>
Reply To:
ToddAndMargo <[log in to unmask]>
Date:
Wed, 6 May 2015 16:46:27 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (109 lines)
On 05/06/2015 04:31 PM, Vladimir Mosgalin wrote:
> 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.
>
>

Hi Vladimir,

Thank you for all the time you have spend with me on this.
Seems to me that I either get over my phobia of software
RAID of just get the most reliable SSD I can find and talk
the customer out of RAID.

-T


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ATOM RSS1 RSS2