|
kmoorevs wrote: Question: Has anyone here actually experienced a failure with an SSD?
Yeah, my work laptop always had an SSD C drive and a HDD D drive.
When I quit my job I bought the laptop and it had to be formatted.
After that I only had a C drive, but I didn't think much of it (I just thought I had multiple partitions before, which were now removed to one big partition).
However, my laptop often failed to start after that and when it did it took minutes instead of the usual seconds.
Every morning was a struggle to start the laptop...
So I called Dell support and it turned out my old C was an SSD and my new C was the HDD.
The SSD got busted for some reason and never could be read after the format.
A Dell engineer replaced it (just within the warranty!) and I never had issues again.
|
|
|
|
|
I've read the MTBF on SSDs was something like 20 years, but for HDDs it was only like 5.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
That would depend a lot on what you use them for.
|
|
|
|
|
I'm sure it does. I think that was an average for consumer use.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
The problem is that they wear out in different ways.
For SSDs they should call it MWBF instead. (Mean Writes Before Failure)
|
|
|
|
|
That's true but MTBF accounts for that in its own way. Obviously the causes are different, but failure is failure for the purposes of this. With modern tech, including advance wear leveling, you get about 20 years out of a drive before your writes fail.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I believe the introduction of static wear levelling was the game changer for SSDs
|
|
|
|
|
Next time, run chkdsk /f before defender. If you have bad sectors you want to mess with them as little as possible before taking an image.
In my experience, the upside with classic spinners is that they generally do warn you, before giving up for good. SSDs tend to just die without any warning at all.
This doesn't stop me from using them though, rather the opposite. But I still use classic spinners for long term storage and any type of transaction log.
|
|
|
|
|
Quote: But I still use classic spinners for long term storage and any type of transaction log
Ditto!  And for storing drive images in a normally disconnected drive.
|
|
|
|
|
Can't say I've had a fatal failure yet [*] but every time I hear about SSD failures, the story pretty much ends with the statement that the data is pretty much completely unrecoverable, unlike spinning disks.
[*] My only experience so far with a failing SSD goes back to my first one, a 64GB Kingston. Not that it contained any data I care about, but suddenly one day, as I wanted to repurpose it, I found out it refused to delete the existing partition and let me start over. Nothing I tried, in fact, managed to delete the partition or just reformat it.
|
|
|
|
|
Quote: Nothing I tried, in fact, managed to delete the partition
Are you familiar with (the dangerous utility) Diskpart? Next time run the Diskpart command 'clean' on the drive. If that does not knock the drive back to what it was before it had its first partition, etc., nothing will work. By the way: Diskpart is not for the faint of heart!
modified 8-Dec-19 16:14pm.
|
|
|
|
|
Cp-Coder wrote: Next time run the Diskpart command 'clean' on the drive. If that does not knock the drive back to what it was before it had its first partition, etc., nothing will work.
the "dban" boot cd can do that kind of job pretty good too
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I'm not familiar with that, but the nice part about Diskpart is that it is an integral part of Windows. You can invoke it with a Powershell command.
|
|
|
|
|
mmmhhh... good to know.
DBan is the best option for "paranoia-modus"
There are several levels, in the most paranoic one, it writes the full disk with encrypted junk, deletes the content and then overwrites it again with NULL-Bytes, that X times in a loop.
I once didn't check the options correctly and had to wait almost 3 days until it was done. I didn't want to cancel, just in case it would make the disk unreadable due to something not correctly ended
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
"Dangerous"? Please...
The problem with diskpart, with this drive, is that it's not low-level enough (if that's even possible). I've tried much more advanced utilities, including the drive's own manufacturer's. Even DBAN (as others below this message have suggested) couldn't make much of it (I forget exactly how it failed, but the partition is still there...)
|
|
|
|
|
I've had two external HDDs "fail".
In both cases, it was the rinky-dink PCBs in the enclosures that failed. The drives were fine.
Don't do anything drastic until you've taken them out of the enclosures and physically mounted them somewhere else.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I did experience an SSD failure a few years ago, when they were relatively new on the market. I haven't experienced one since.
I have had a few HDDs fail me over the years.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Okay so I was kind of surprised this compiled:
if (null == default(T)) _array[_head] = default(T);
Where T is a generic type parameter
The reason I thought it wouldn't is because T can be a value type.
It's too bad I don't know if that operation boxes or not. It's kind of important. Now I have to disassemble just to know the spec on it. You should never have to do that, especially for a language that is supposed to be standardized, because if there's no standard for that behavior then different implementations are free to implement it how they like.
Maybe it's in the spec and it got buried, but I can't find it to save my life. Grrr.
Edit: Yes, it causes the default(T) to be boxed  (at least in MS's DNF implementation)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
modified 8-Dec-19 10:12am.
|
|
|
|
|
Why would you expect them to document it? Nullable types weren't in the original C# - they arrived at .NET 2.0 - so a value type would have to be boxed to compare it against null since only reference types can contain null values.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
They should be amending, and typically do amend the specs when new versions are released. They have to in order for it to be standards based. The other reason to consider that it might not have been boxed was added optimization for T once they added generic support post 1.x
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: Okay so I was kind of surprised this compiled:
if (null == default(T)) _array[_head] = default(T);
Where T is a generic type parameter
Strange, why won't it compile? It just says, "if the default value for this type parameter is null, then set the element at the _head in the _array member as the default value of type T."
To prevent this code from being compiled, you should apply the constraints, that would limit the type that can be used here. C# provides class, struct, notnull and many more as a constraint in this case. To prevent the code from being compiled, you should consider these.
class GenericArray<T> where T : class
{
public void Insert(T parameter)
{
if(default(T) == null)
{
Console.WriteLine("null");
}
}
}This code would not accept a value-type (System.ValueType) in the parameter, and would prevent the code from building; note that it is not the line you expect to break the build.
But remember, the application of these constraints would also make your if...else blocks less sensible. For example, if you apply the class constraint then the condition is always true, and the value will always be set to null in the head element, which would be repetition as the default value is set to null for you. Similarly, application of struct as a condition would make this line of yours not build.
class GenericArray<T> where T : struct
{
public void Insert(T parameter)
{
if(default(T) == null)
{
Console.WriteLine("null");
}
}
}
I like reading the template programming concepts, although C# is no way near template programming (such as in C++), the promise of template programming is huge.
Template metaprogramming - Wikipedia
Quote: It's too bad I don't know if that operation boxes or not.
One of the times when I really miss the old MSDN documentation which was professional, and always accurate. Now, anybody (including peeps like me) can edit the document from one point-of-view and mess it from all other angles. I recommend adding these points to the Microsoft Docs, you can do that with a GitHub account. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
To be clear, I didn't want it to not compile. I actually wanted it to work if it didn't box.
Turns out i don't really need the check there anyway, I was primarily just seeing if it would work before i inserted it into my more complex routines that do batch copies of segments of the array.
What I wanted was to avoid doing things like calling Array.Clear unless it was a reference type but i wanted to check that without boxing. Unfortunately it boxes. That's okay for my methods where i must clear whole segments, but not where I'm clearing an individual item.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Is this new behavior?
I remember doing stuff like that and getting compile time errors saying T could be a value type which can never be null.
I've always had to add a class constraint.
|
|
|
|
|
It apparently depends on how you use it. It might be that the default(T) scenario is a special case.
Or maybe it works in comparisons but not assignments.
I don't know really, that's just casting the bones. But I do know in some cases you're right, it won't compile.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: Or maybe it works in comparisons but not assignments.
I think that's it.
Assignments can't be done, just as new T().
Perhaps you can work around boxing.[^]
public void MyVoid<T>(T something)
{
if (typeof(T).IsValueType)
{
}
else
{
}
}Although this is probably not about your code, but code others might possibly write?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
