When Solid State Drives Are Not That Solid • Hacker News Board

Re: When Solid State Drives Are Not That Solid

#11

Post by bbcbasic » Tue, Jun 16, 2015, 1:43 AM UTC

I have a Samsung SSD 850 PRO 512GB in my Windows PC. And I have TRIM enabled in Windows:

     > fsutil.exe behaviour query DisableDeleteNotify
     DisableDeleteNotify = 0

Should I be worried?

Re: When Solid State Drives Are Not That Solid

#12

Post by [deleted] » Tue, Jun 16, 2015, 1:46 AM UTC

kbar13 wrote: post #7

if one machine failed and failover kicked in correctly, why was the engineer paged?

[deleted]

Re: When Solid State Drives Are Not That Solid

#13

Post by microcolonel » Tue, Jun 16, 2015, 2:00 AM UTC

I've had issues with these samsung 8xx drives, unfortunately they all happened at once. I gave up on their RMA/warranty process because I was bounced back and forth between the same two numbers a few times. Either side said that the other was in charge of this process(samsung bought the SSD division from seagate... or was it seagate that bought the HDD division from Samsung? To this day I have no clue.).

Re: When Solid State Drives Are Not That Solid

#14

Post by ploxiln » Tue, Jun 16, 2015, 2:06 AM UTC

bbcbasic wrote: post #11

I have a Samsung SSD 850 PRO 512GB in my Windows PC. And I have TRIM enabled in Windows: > fsutil.exe behaviour query DisableDeleteNotify DisableDeleteNotify = 0 Should I be worried?

Released versions of Windows do not use queued trim.

(That's why serious bugs like this can happen ;)

Re: When Solid State Drives Are Not That Solid

#15

Post by malbs » Tue, Jun 16, 2015, 2:08 AM UTC

bbcbasic wrote: post #11

I have a Samsung SSD 850 PRO 512GB in my Windows PC. And I have TRIM enabled in Windows: > fsutil.exe behaviour query DisableDeleteNotify DisableDeleteNotify = 0 Should I be worried?

Pretty sure this is an interaction issue with Samsung drives, trim support, and the Linux kernel, so no, you don't need to be worried.

Re: When Solid State Drives Are Not That Solid

#16

Post by kuschku » Tue, Jun 16, 2015, 2:09 AM UTC

ploxiln wrote: post #9

lvs wrote: post #4

Can someone clarify the article's claim that these Samsung drives are really "broken" as such? We have a few of these on 3.13 and 3.16 kernels and ext4 with no problems. It seems that there must be something unique to their application in order to expose these trim failures.

Do you have the "discard" mount option enabled? Do you have a cron job that runs the "fstrim" command? It's possible your systems are not running trim. Or maybe your ext4 filesystems have little activity and you haven't had enough corruption to notice yet :) Also, some Samsung 800 series drives only gained this bug in a recent firmware update (840 EVO specifically).

So, if I don’t update the firmware of my 840 EVO, I can continue using it with discard?

Re: When Solid State Drives Are Not That Solid

#17

Post by InclinedPlane » Tue, Jun 16, 2015, 2:11 AM UTC

kbar13 wrote: post #7

if one machine failed and failover kicked in correctly, why was the engineer paged?

Depends on how much spare capacity they had. Being one failure away from going down is an emergency situation at many places.

Re: When Solid State Drives Are Not That Solid

#18

Post by guns » Tue, Jun 16, 2015, 2:13 AM UTC

ploxiln wrote: post #9

lvs wrote: post #4

Can someone clarify the article's claim that these Samsung drives are really "broken" as such? We have a few of these on 3.13 and 3.16 kernels and ext4 with no problems. It seems that there must be something unique to their application in order to expose these trim failures.

Do you have the "discard" mount option enabled? Do you have a cron job that runs the "fstrim" command? It's possible your systems are not running trim. Or maybe your ext4 filesystems have little activity and you haven't had enough corruption to notice yet :) Also, some Samsung 800 series drives only gained this bug in a recent firmware update (840 EVO specifically).

The 840 EVO joined the club with firmware EXT0DB6Q, which itself is a nasty little hack around a fundamental design problem with the tightly packed NAND cells.

Linux 4.0.5 ships with the patch linked above, but for a while you had to roll with a kernel built from source.

EDIT: The blatant file corruption issues only manifested after updating to firmware EXT0DB6Q.

Re: When Solid State Drives Are Not That Solid

#19

Post by ChuckMcM » Tue, Jun 16, 2015, 2:14 AM UTC

Nice debugging story. When I was at NetApp there were lots of times when drive firmware for the 'less used' options would fail. On the fiber channel drives the 'write zeros' command which was supposed to zero a drive was notorious in its in ability to achieve something that simple. When Google looked at (I don't know if they finally deployed it) the disk encryption technology it worked differently disk to disk and firmware rev to firmware rev. I think it was Brian Pawlowski at NetApp that said "You can count on two things working right in a hard drive, read, write, and seek." The joke being that you needed all three of them to work for reliable disk operation.

Re: When Solid State Drives Are Not That Solid

#20

Post by ploxiln » Tue, Jun 16, 2015, 2:18 AM UTC

kuschku wrote: post #16

ploxiln wrote: post #9

Earlier quoted context omitted.

Do you have the "discard" mount option enabled? Do you have a cron job that runs the "fstrim" command? It's possible your systems are not running trim. Or maybe your ext4 filesystems have little activity and you haven't had enough corruption to notice yet :) Also, some Samsung 800 series drives only gained this bug in a recent firmware update (840 EVO specifically).

So, if I don’t update the firmware of my 840 EVO, I can continue using it with discard?

I'm not sure exactly when the first 840 EVO firmware which advertised queued trim support (along with SATA 3.1/3.2 support) was released, but I think that if you last updated firmware (or acquired the drive) before October 2014, you're safe.

However, if you don't update your firmware, you'll suffer from significant performance degradation when reading old files: http://www.anandtech.com/show/9196/samsung-releases-second-8...