Samsung 840 EVO read speed drops on old-written data in the drive - Page 267 - Overclock.net - An Overclocking Community

Forum Jump: 

Samsung 840 EVO read speed drops on old-written data in the drive

Reply
 
Thread Tools
post #2661 of 3282 (permalink) Old 04-23-2015, 10:22 AM
New to Overclock.net
 
malventano's Avatar
 
Join Date: Sep 2013
Posts: 270
Rep: 50 (Unique: 28)
Quote:
Originally Posted by Darkhaze View Post

How old is the 850 evo, and how old the 840 evo when the problems presented? I'm not trying to argue, I'd honestly like to know.
840 EVO:
- Slowed after ~3 months prior to the first update.
- The update (which forced a refresh and reset the counter) took ~4-6 to slow to the same level.
- The current update snapped read speeds back to full on data that was 6 months old.
850 EVO:
- Launched 5 months ago. No issues.
- (I've had data on samples starting 6 months ago. No sign of slowing.)

My guess is that Samsung had a bug in the firmware's ability to compensate for cell drift, and that bug was not fully corrected in their first attempt at a fix. All SSDs experience this drift, but the 840 EVO also employed a different type of wear leveling that leaves old data in place as opposed to periodically rewriting all data. If other SSDs had the same sort of bug, those actively used would never see stale data slowing, because no data is actually stale on the flash. Samsung had delayed the 850 EVO launch by a bit, and I suspect it was so they could be sure this issue was not present before they launched it.
malventano is offline  
Sponsored Links
Advertisement
 
post #2662 of 3282 (permalink) Old 04-23-2015, 10:29 AM
New to Overclock.net
 
luismc's Avatar
 
Join Date: Feb 2015
Posts: 32
Rep: 7 (Unique: 6)
Quote:
Originally Posted by malventano View Post

The new firmware may not like a huge stack of queued TRIM commands being piled up on the SSD *while* trying to boot. If anyone else can reproduce this, I'll pass the info along to Samsung.

Side question - why do you need to TRIM the SSD on every boot? Mint should be a new enough kernel to TRIM deleted / moved / cleared areas of the SSD as those events happen. Issuing another TRIM to those empty areas on every boot is redundant, and might force extra flash wear on some SSDs (some may consolidate and clear some partially filled blocks, depending on how they implemented TRIM).

Most Linux distributions do scheduled TRIM requests and not real time ones, unless you specifically mount the filesystem with the "discard" parameter. They seem to think it's more efficient this way.
luismc is offline  
post #2663 of 3282 (permalink) Old 04-23-2015, 10:36 AM
New to Overclock.net
 
G4Virus's Avatar
 
Join Date: Sep 2014
Posts: 111
Rep: 22 (Unique: 12)
Quote:
Originally Posted by Nearseer View Post

I have updated the firmware(EXT0DB6Q) with Magician 4.6 under Win7 on my 840EVO 120GB.
(I have dual boot system, Linux Mint 17.1 on 840EVO, Win7 - just for some windows programs - on HDD)

Firmware update was successful everything seems to work, under Win7.

When I started Linux Mint I got a lot of file system errors, freezes, and a system that couldn't boot up.


I've find out the problem is with TRIM. (TRIM seems to be OK under Win7)
The SSD become become totally unstable after the TRIM command (fstrim) on Linux Mint 17.1.
I've got massive I/O errors.

I had to disable the scheduled(on every boot) TRIM functionality under Linux Mint.
After that, Mint was booted normally, now 840EVO seems to be stable (no sign of data loss).

TRIM was fully functional with the previous EXT0CB6Q firmware on Linux Mint 17.1.

Interesting read there in the man pages.
http://man7.org/linux/man-pages/man8/fstrim.8.html


Any way do you use discard for the partitions on the SSD in /etc/fstab ?
Thats what i always did and what I did on my frinds 840 EVO on is Mint install.
discard should be good enough on modern SSD's any way.
G4Virus is offline  
Sponsored Links
Advertisement
 
post #2664 of 3282 (permalink) Old 04-23-2015, 10:40 AM
New to Overclock.net
 
Join Date: Apr 2015
Posts: 5
Rep: 1 (Unique: 1)
I bought my first SSD (sadly an 840EVO frown.gif ) in 2014 September.

After a fresh Mint install I followed the instructions from here:
https://sites.google.com/site/easylinuxtipsproject/ssd

I disabled the default weekly TRIM ("cron job"),
and added the TRIM command to /etc/rc.local.

I have no problem with this method at all.


Now in my system(Dell E5400) under Linux Mint 17.1 the TRIM command cause I/O malfunction on 840EVO with the new firmware.
It doesn't matter that the system triggers TRIM with the default weekly "cron job" or manually I triggered it.

(my native language is not English, so my spelling may be bad sometimes, sorry)
Nearseer is offline  
post #2665 of 3282 (permalink) Old 04-23-2015, 10:49 AM
New to Overclock.net
 
Join Date: Jan 2015
Posts: 731
Rep: 56 (Unique: 31)
I think the limit is reset every couple of hours, because i refreshed my Magician and it just prompted me for the FW update.

Palorim12 is offline  
post #2666 of 3282 (permalink) Old 04-23-2015, 10:51 AM
New to Overclock.net
 
Anteus's Avatar
 
Join Date: Apr 2015
Posts: 3
Rep: 0
Quote:
Originally Posted by Palorim12 View Post

I think the limit is reset every couple of hours, because i refreshed my Magician and it just prompted me for the FW update.

I waited for a while and then restarted magician a couple of times then i got it
Anteus is offline  
post #2667 of 3282 (permalink) Old 04-23-2015, 10:53 AM
New to Overclock.net
 
G4Virus's Avatar
 
Join Date: Sep 2014
Posts: 111
Rep: 22 (Unique: 12)
Quote:
Originally Posted by Nearseer View Post

I bought my first SSD (sadly an 840EVO frown.gif ) in 2014 September.

After a fresh Mint install I followed the instructions from here:
https://sites.google.com/site/easylinuxtipsproject/ssd

I disabled the default weekly TRIM ("cron job"),
and added the TRIM command to /etc/rc.local.

I have no problem with this method at all.


Now in my system(Dell E5400) under Linux Mint 17.1 the TRIM command cause I/O malfunction on 840EVO with the new firmware.
It doesn't matter that the system triggers TRIM with the default weekly "cron job" or manually I triggered it.

(my native language is not English, so my spelling may be bad sometimes, sorry)

I was no aware that Mint or Ubuntu had a cron job for trim. I always add discard to fstab any way for frinds, works on swap and ext4 at least.
Also that guide seems to emphasis on removing fstrim from the cron jobs.
I personally dont see a point in having it in rc.local either on boot as it suggests.
Tough I run gentoo and all the guides I read suggest using discard in fstab since that allows the kernel to pass trim commands as needed. I ahve used discard since the second generation SSD's like the OCZ vertex on by own linux and frinds linux systems, OCZ Vertex, Intel 320, Crucial M4, 840, 840 EVO, MX100 to name some of them.

So I would just disable that fstrim cron jobb, in my case with gentoo I wont have that running out of the box any way since its basicly linux from scratch and then I just add discard to fstab on any swap or ext4 partitions on the SSD.

This is my servers fstab config for the ssd. discard for swap and ext4 and notime, notime disables the time stamp updates on the filsystem when ever a file is accessed, read that is not written.
Code:
/dev/sda1               /boot           ext4            noauto,discard,noatime          1 1
/dev/sda3               /               ext4            noatime,discard                 0 0
/dev/sda2               none            swap            sw,discard                      0 0

Any way I dont like that guide you linked, not seen one like it before. discard in fstab seems to be the preferred method and I cant see the downside of the kernel issuing trim commands when its actually needed.

But any way its alarming that the new firmware caused that problem but any way I would not use trim that way on a linux system. But its good to know that ubuntu and mint uses a cron job by default so one might need to disable that and just add discard to /et/fstab instead and thats how I prefer it.
G4Virus is offline  
post #2668 of 3282 (permalink) Old 04-23-2015, 11:02 AM
New to Overclock.net
 
luismc's Avatar
 
Join Date: Feb 2015
Posts: 32
Rep: 7 (Unique: 6)
Quote:
Originally Posted by G4Virus View Post

Tough I run gentoo and all the guides I read suggest using discard in fstab since that allows the kernel to pass trim commands as needed.

I'm not saying the guides you've read don't say so, but the official wiki (https://wiki.gentoo.org/wiki/SSD) recommends the fstrim method.

Anyway, I'm thinking that it might be more related to the amount of trim requests within a short time than the method that triggered them. @Nearseer You might want to create a huge file and delete it and see if that causes any errors too.
luismc is offline  
post #2669 of 3282 (permalink) Old 04-23-2015, 11:04 AM
New to Overclock.net
 
Join Date: Apr 2015
Posts: 5
Rep: 1 (Unique: 1)
There is no discard function set for the SSD in my fstab.

Some minutes ago I set discard option in fstab and got the I/O errors...

Fortunately I managed to set back the previous settings.

So now, without discard option (and without TRIM) the 840EVO is working again.
Nearseer is offline  
post #2670 of 3282 (permalink) Old 04-23-2015, 11:08 AM
New to Overclock.net
 
luismc's Avatar
 
Join Date: Feb 2015
Posts: 32
Rep: 7 (Unique: 6)
Quote:
Originally Posted by Nearseer View Post

There is no discard function set for the SSD in my fstab.

Some minutes ago I set discard option in fstab and got the I/O errors...

Fortunately I managed to set back the previous settings.

So now, without discard option (and without TRIM) the 840EVO is working again.

So its seems that TRIM is completely broken?

@g4virus Did you update your firmware? And you're not having issues?

And maybe Windows' people should have a look at their system logs too...

*edit*
Btw, no TRIM and no static wear levelling doesn't sound like a great combination.
luismc is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off