[CentOS] issue_discards in lvm.conf

[Dan Hyatt]

   I worked in the SSD lab at STEC for a while, testing SSD's and fixing 
SSD's that failed...

When I was working in the lab on the Zuess  drives (First enterprise 
class SSD drive) . When the drives came back from our customers hosed, 
all we had to do was re-flash the firmware (helps if you have the 
software and the firmware to reflash the drives, the hardware was your 
basic server).  I don't know about you problem, or which manufacturing 
process drives you are using...but the Zeuss drives only needed a 
firmware reflash.

This was just a 2u server with a software program that would allow me to 
reflash the drives.

There were 2 kinds of SSD drives (2 manufacturing processes). The 
consumer grade which had a MTF of 2 years, and/or X writes.   There was 
the other process, enterprise class drives which had a MTF of ~ (yes 
infinity) theory was they would never fail.

I knew how to blow up the drives, run them well beyond the capacity of 
spinner drives. But then I would flash the firmware and the drive would 
be good as new.  I would be running about 200 music videos at the same 
time to get enough throughput to cause it to crash. The goal was to find 
*when* they blew up, so we could limit them in firmware before then.

We all know manufacturers know how to make benchmarks lie. They told me 
which tests to run to make our drives blow away the spinners, and which 
ones not to do. The very fragmented drives RO, SSD blew away the 
spinners, but Writting sequentially (both blank drives to start) there 
was little difference.

When our customers (the major SAN manufacturers) returned the drives. 
There was one of two things wrong with them...
1. They got a drive with a bad firmware version. Reflash and it is fixed.
2. Their design was good enough for spinner drives but did not follow 
the standard for [SAS|FIBER]  and we found the problem, advised them 
what it was so they could change thier design.

I remember when I dropped a $40k sample...lab manager looked at 
me...stared at me...then burst out laughing. The enterprise SSD's were 
nearly indestructible and when someone dropped on for the first time, 
they would *try* to look angry, but then would burst into laughter at 
the nervous engineer.

If I got any details slightly off, hey it was a decade ago!   :)


On 6/12/2014 1:29 PM, James B. Byrne wrote:
>
> On Thu Jun 12 17:21:43 UTC 2014, John R Pierce pierce at hogranch.com wrote:
>
>> On 6/12/2014 10:12 AM, m.roth at 5-cent.us wrote:
>>> We use two methods: for the drives that are totally dead, or*sigh*  the
>>> SCSI drives, they get deGaussed. For SATA that's still running, we use
>>> DBAN.*Great*  software. From what I've read, one pass would probably be
>>> good enough, given how data's written these days. With my name certifying
>>> it, I do paranoid, and tell DBAN the full 7-pass, DoD 5220.22-M. I
>>> *really*  don't think anyone's getting anything off that.
>> if the drive has remapped tracks, there's stale data on there you can't
>> erase with DBAN.
>>
>>> We don't have any SSDs, so I can't speak to that. Bet you could deGauss
>>> them, easily enough. Or maybe stick 'em on a burner on a stove to get over
>>> the Curie point....*
>> degaussing would do nothing to flash memory, its semiconductor,
>> not magnetic.
> An EMP gun on the other hand. . .
>

-- 
  
Dan Hyatt