Samsung 840 EVO Performance Degradation on Old Files

[readymix]

I've noticed this old data thing from time to time or some form of it. not only evo's as I don't have any and not only Samsung's.

 

[IGemini]

I suppose my EVO issue is tame by comparison. My benchmark reads were only coming in at half of what they should've been for a while but seems better since I had to reinstall Windows recently. I stopped playing Skyrim for a few months, when I restarted my game it took a LONG time to do the initial reload, maybe 2-3 minutes. Not so bad since then.

 

[fire400]

just got the 840 evo for a hundred bucks with 2 year warranty from micro center in mpls a few weeks ago.

tempted now to flake it with linux "bios SSD freeze" software to get my hundred dollars back later on, to get gift card and get an 850 pro.

currently mine is sitting in an asus celeron 2GB netbook, and the performance on win8.1 pro x32 is truly phenom...

 

[Carfax83]

Tested this myself and yep, my 1TB Samsung Evo is definitely suffering from this problem..

Would it also affect games? I haven't noticed any longer loading times on games or stuttering due to slow reads..

 

[Carfax83]

Actually scratch that. I have noticed a decline in loading speed. Crysis 3 in particular seems to be taking longer to load, and I'm noticing odd stuttering that I never got before when I first loaded it. I loaded Crysis 3 on my SSD in May of this year, so that would definitely be long enough for the bug to affect the game's performance..

At least Samsung are aware of the issue and are promising a fix so I guess I can't complain too much..

 

[h9826790]

It will fix the issue for some files, but many system files won't get moved, and they relate to overall system "snappiness". The only true fix (according to the Toms thread) is a backup/system restore.

May be because I am with the OSX. For me, a full defrag (by 3rd party software) every few months basically means all files will be moved. So, I never actually notice any performance degradation on my 1T 840 Evo.

 

[Engineer]

I think you can simply defrag the SSD. In fact, defrag a SSD for about every 6 months is not a bad idea, and it helps to improve or maintain the SSD's performance. No matter it's a Evo or not.

Why would you want to defrag an SSD? The wear leveling routine will take care of moving the blocks around and cleaning up (along with garbage collection and TRIM). Everything that I've read on an ssd recommends against defragging an SSD as it simply wears it out faster (not that it matters much because it would take years anyway) and serves no purpose (doesn't help speed, etc).

 

[IGemini]

AT confirms the update is coming October 15th.

http://www.anandtech.com/show/8570/...o-read-performance-bug-coming-on-october-15th

 

[h9826790]

Why would you want to defrag an SSD?

The SSD is not a device that should avoid any kind of writing action. Perform some maintenance every few months won't shorten it's life significantly. Of course, I won't recommend to defrag a SSD every day or week.

Even thought the SSD is "headless", every single fragment of a file that has to be written or fetched still costs CPU cycle and latency. To access a file that is seriously fragmented is significantly slower than a file in only few fragments. This slowdown is at the OS filesystem level because many more IOs are required (for each fragment, the filesystem has to create an IO request, send it over serial lines to the SSD, the disk then decode the packet, do the transfer, and send the response back to the filesystem). Even though writing a file, the filesystem has to work harder to find free space if it's only available in small chunks scattered across the LBA range.

Believe it or not, some users actually report that they can feel the speed difference after this housekeeping action. To make it clear, only a heavily fragmented SSD will benefit from defrag. I personally do this about every 6 months. And I will check if the disk is seriously fragmented (e.g. more than 80%) before I take action.

TRIM and garbage collection won't help to reduce the additional CPU cycles and latency. That's why defrag still required very occasionally.

 

[Atreidin]

Believe it or not, some users actually report that they can feel the speed difference after this housekeeping action.

The placebo effect is amazing.

 

[h9826790]

Severely fragmented SSDs are significantly slower in the real world than SSDs with mostly contiguous files. That's not placebo effect, but real world result.

SSD doesn't suffer the same mechanical latencies as HDD, however, it has exactly the same per IO CPU/latency costs as a spinner. This is the truth.

 

[hojnikb]

Severely fragmented SSDs are significantly slower in the real world than SSDs with mostly contiguous files. That's not placebo effect, but real world result.

SSD doesn't suffer the same mechanical latencies as HDD, however, it has exactly the same per IO CPU/latency costs as a spinner. This is the truth.

Wow, what a load of bollocks.
SSDs are BY DESIGN very very fragamated devices. Its the only way to extract 500MB/s speeds.

So yeah. While degragging does help EVO, but it helps because of a completly different reason. While HDDs dont like fragamatted data (because head needs to move like its on drugs) SSDs simply dont care.
EVO benefits from degragging because defrag apps rewrite everything thus refreshing old data and consiquently boosting read speeds.

 

[h9826790]

Try this yourself please, and then tell me the answer.

V:\SSD\Frags> frag-it    // alternately append a small file to two different files 300,000 times

V:\SSD\Frags> contig -a *   // display fragmentation

V:\SSD\Frags\a.file is in 84518 fragments
V:\SSD\Frags\b.file is in 84482 fragments
V:\SSD\Frags\frag-it.bat is defragmented

V:\SSD\Frags> copy b.file c.file   // copy to new files
        1 file(s) copied.

V:\SSD\Frags> copy c.file d.file
        1 file(s) copied.

V:\SSD\Frags> dir

 Directory of V:\SSD\Frags

2014-08-30  09:40       768,200,000 a.file
2014-08-30  09:40       768,200,000 b.file
2014-08-30  09:40       768,200,000 c.file
2014-08-30  09:40       768,200,000 d.file
2014-08-30  09:21               140 frag-it.bat

V:\SSD\Frags> contig -a *    // check fragmentation

V:\SSD\Frags\a.file is in 84518 fragments
V:\SSD\Frags\b.file is in 84482 fragments
V:\SSD\Frags\c.file is defragmented
V:\SSD\Frags\d.file is defragmented
V:\SSD\Frags\frag-it.bat is defragmented

V:\SSD\Frags> rammap     // flush all filesystem caches ("Empty standby list")

// Read the files with 'timeit' enabled

V:\SSD\Frags> wc -l a.file
   33400000     a.file
  Elapsed (real) time:    0:00:13.40  h:m:s       13.40 secs
  Total CPU time:         0:00:04.49  h:m:s        4.49 secs      33.5 % of elapsed time

V:\SSD\Frags> wc -l b.file
   33400000     b.file
  Elapsed (real) time:    0:00:12.93  h:m:s       12.93 secs
  Total CPU time:         0:00:04.80  h:m:s        4.80 secs      37.2 % of elapsed time

V:\SSD\Frags> wc -l c.file
   33400000     c.file
  Elapsed (real) time:    0:00:04.82  h:m:s        4.82 secs
  Total CPU time:         0:00:04.76  h:m:s        4.76 secs      98.6 % of elapsed time

V:\SSD\Frags> wc -l d.file
   33400000     d.file
  Elapsed (real) time:    0:00:05.37  h:m:s        5.37 secs
  Total CPU time:         0:00:05.32  h:m:s        5.32 secs      99.2 % of elapsed time

Obviously the fragmented files read about 150% slower than the contiguous files (13s vs 5s). Please tell me why. And this test is not just valid on the Evo.

Again, I only said that a seriously fragmented SSD will benefit from defrag. SSD not require defrag is totally wrong. They just suffer less, and should not be defraged frequently.

If you believe that fragment has no effect on SSD performance, or even can increase the performance. Please show me the proof.

 

[Cerb]

Wow, what a load of bollocks.
SSDs are BY DESIGN very very fragamated devices. Its the only way to extract 500MB/s speeds.

So yeah. While degragging does help EVO, but it helps because of a completly different reason. While HDDs dont like fragamatted data (because head needs to move like its on drugs) SSDs simply dont care.
EVO benefits from degragging because defrag apps rewrite everything thus refreshing old data and consiquently boosting read speeds.

All ATA SSDs "suffer" from that same issue. Technically, HDDs too, they're just much slower than the whole communication chain, making the difference immeasurable with them. The SSD's controller, your SATA controller, your SCSI layer, and your ATA layer, get limited due to the higher number of requests. You can't get 500MBps reads on a severely fragmented file, with any SATA SSD today, because the real speed will trend towards the 4K speed. What's going on under the hood doesn't matter, here, just what's going on between the program (which sees a linear byte string), the driver layers (converting that into the n total requests for data fragments), and the SATA interfaces (requesting and returning the appropriate LBAs).

SSDs do not cure this problem, and they cannot cure this problem (however, as latencies reduce, it may be possible for future NVMe SSDs to make it an academic problem). File system implementations can cure it, and programs choosing to keep their edits on files large can also make it a non-issue, which would benefit both HDDs and SSDs (FI, write out changes in MBs at a time, or re-write the whole file, if smaller than such a threshold).

But, only severely fragmented files need worrying about. We still have urban mythology from the 9x days, when the OS wouldn't read files out of order, of defragging being super important, plus insufficient from the OS. and it is spurred on by companies selling tweaking tools. The reality is that random access, read-ahead, out of order fragment reading (been done since either NT4 or 2000), minor fragmentation is a complete non-issue with any common storage medium, and only a small percentage of users need any defragging at all, of any files, ever, due to excessive fragmentation by their applications.

 

[Engineer]

The SSD is not a device that should avoid any kind of writing action. Perform some maintenance every few months won't shorten it's life significantly. Of course, I won't recommend to defrag a SSD every day or week.

Even thought the SSD is "headless", every single fragment of a file that has to be written or fetched still costs CPU cycle and latency. To access a file that is seriously fragmented is significantly slower than a file in only few fragments. This slowdown is at the OS filesystem level because many more IOs are required (for each fragment, the filesystem has to create an IO request, send it over serial lines to the SSD, the disk then decode the packet, do the transfer, and send the response back to the filesystem). Even though writing a file, the filesystem has to work harder to find free space if it's only available in small chunks scattered across the LBA range.

Believe it or not, some users actually report that they can feel the speed difference after this housekeeping action. To make it clear, only a heavily fragmented SSD will benefit from defrag. I personally do this about every 6 months. And I will check if the disk is seriously fragmented (e.g. more than 80%) before I take action.

TRIM and garbage collection won't help to reduce the additional CPU cycles and latency. That's why defrag still required very occasionally.

Well, that all makes sense (including the test above). Now the question, how often would you have a file(s) become so fragmented (80,000 fragments or whatever the magic number is that makes a file 'severely' fragmented?) that this 'NEEDS' to be done? Maybe on a database that is constantly changing? Possibly the OS page file?

Most files aren't going to break into 80,000 fragments unless absolutely heavily used (abused?)?

 

[pw257008]

Not to veer off topic, here, but anyone know a good defrag program for Linux as a temp fix to this problem?