SSD Write Endurance 25nm Vs 34nm

[One_Hertz]

The 320 still is not dead ? Has Samsung arrived yet ?

320 still going strong. The reallocated sectors are still quickly rising but the SSD seems fine...

I just got the Samsung 5 minutes ago. First I have to fix the broken power connector. I probably wont get to it today, but I should get it done tomorrow. Johnw - what read tests do you want done?

After the read tests, I will attempt to write a translator algorithm onto it (which should take forever considering its state) then pop the NAND off and read it directly.

[johnw]

Johnw - what read tests do you want done?

First, see if you can read anything on the filesystem at all. Just before I broke the SATA power connector, I was unable to get the BIOS to even recognize the SSD. It reached write exhaustion on 2011-Aug-20, but I was still able to read files from it. Then I left it unpowered for a month, and tried to read it again, but the BIOS would not recognize the drive. I fiddled with it a little with no luck, then when I was trying to get it recognized on another computer was when the SATA power connector broke.

The idea was originally to check the MD5 of the ~40GB file on the SSD every month for a year, since consumer SSDs are supposed to be able to retain data, unpowered, for a year after write exhaustion. It seemed like the Samsung did not even last a month, but it would be good for you to double check. If you do manage to mount the file system read-only, then please compute an MD5 checksum on the ~40GB file.

If you are unable to mount the filesystem at all, then you can proceed with whatever tests you would like to try.

[FoLmEr]

Hi

First of all, thank you for doing this great project - I've been following this thread every day for weeks now with great interest.

Having an SF-22xx drive myself, I've been especially interested in this aspect of the thread. I've owned a Force GT 120GB for a bit more than a month now and I've had crashes with the drive disappearing from BIOS two times only. While not much compared to other folks, it's still annoying, and maybe even more annoying knowing I've got a... fragile... piece of hardware with the potential to cause trouble when it feels like doing so.

So, may we have a recap on the SF issue and can you say anything concrete on the matter in terms of causes/workarounds at this time?

Also, I don't mind helping out if you have some specific BIOS settings/workloads/etc to try out if it brings the world closer to solving the infamous SF problem. This is my only PC tho and it's not running 24/7, so I may not have the same resources but I'll do what I can if needed.

What I have observed around the SF bug myself is that it's only happened during an overclock with an OFFSET vcore while running the BOINC client with the specific settings of 100% CPUs used and 60% CPU time. This configuration results in an erratic load on the processor going literally from 0% to 100% and back down to 0% in under a second with the vcore being thrown around like mad. The first time it crashed within 2 hours of this load and the second time it happened within 10 hours of this load. C3/6 states disabled, altho C1E and EIST have been enabled.

At the moment I'm testing the same CPU workload but with a static vcore.

[Ao1]

.....the idea was originally to check the MD5 of the ~40GB file on the SSD every month for a year, since consumer SSDs are supposed to be able to retain data, unpowered, for a year after write exhaustion. It seemed like the Samsung did not even last a month, but it would be good for you to double check. If you do manage to mount the file system read-only, then please compute an MD5 checksum on the ~40GB file.

If you are unable to mount the filesystem at all, then you can proceed with whatever tests you would like to try.

Based on what happened to your drive (and what appears to be happening to One-Hertz's drive) I suspect that is based on MWI exhaustion, not the physical exhaustion of the NAND. It’s a grey however area that manufacturers should confirm.

I am interested to see if/ how well the Samsung managed static data. One_Hertz, is this something you can determine?

@ Anvil, I monitored "normal" activity today using DiskMon and when I plugged in the stats it came out as 37% random/63% sequential for writes, with an average write file size of 64KB. Still not sure why ASU came out as mostly random. Will check into it more later.

[johnw]

Based on what happened to your drive (and what appears to be happening to One-Hertz's drive) I suspect that is based on MWI exhaustion, not the physical exhaustion of the NAND.

No, I'm 99% certain that the flash wore out.

[One_Hertz]

One_Hertz,

Do you have to make your own Flash Translation Layer for each drive?

Ideally, if the SSD is accessible through the controller, I would write the logical block address of each sector as the sector content of that sector. Then I would read all the NAND chips directly and have all the data, except it would be in the order it is actually on the flash. The contents of the sectors will allow me to take a very basic look at how the wear leveling algorithm works. Most likely, it will be such a complex mess that I won't be able to figure much out myself, but who knows... it did fail first. I mainly just want to take it apart to see how easily the NAND itself could be read. It might read just fine or it might be a sea of ECC errors. I will see.

First, see if you can read anything on the filesystem at all. Just before I broke the SATA power connector, I was unable to get the BIOS to even recognize the SSD. It reached write exhaustion on 2011-Aug-20, but I was still able to read files from it. Then I left it unpowered for a month, and tried to read it again, but the BIOS would not recognize the drive. I fiddled with it a little with no luck, then when I was trying to get it recognized on another computer was when the SATA power connector broke.

The idea was originally to check the MD5 of the ~40GB file on the SSD every month for a year, since consumer SSDs are supposed to be able to retain data, unpowered, for a year after write exhaustion. It seemed like the Samsung did not even last a month, but it would be good for you to double check. If you do manage to mount the file system read-only, then please compute an MD5 checksum on the ~40GB file.

If you are unable to mount the filesystem at all, then you can proceed with whatever tests you would like to try.

I'll try this. Hopefully it is accessible still.