Jump to content
Corsair Community

Just a couple of questions on SSD's erasing and perfomance degradation


Recommended Posts

As another new owner of one of Corsair Force 3 SSDs, I've got some problems in comprehensing some contradicting opinions on matters mentioned it thread's title. I'll start from my understanding of the problem, that you could criticise me more easly if I'm badly mistaking at some point.

So, SSDs used to have this problem: you can read from it only in "pages" of 4KiB size, and you can write to it in such a "page" of 4KiB - but only if you're writing to the CLEAR pages! If the "page" you are writing your data to have ever been used before (and presuming we don't have TRIM support (for example in my winXP I don't) meaning OS can't tell your drive to clean ALL pages that were occupied by some deleted file after you've removed it from file system; by default only file system's internal tables are modified to mark this space as free, because conventional HDD don't care if they write to dirty or clean sectors; but SSDs CARE!), you can't just write to it, it HAS TO first read a "BLOCK" of data (which is 512KiB size, or 128 "pages") into controller's cache, then CLEAN all this "block" at once on drive (it can't clean individual "pages", only a "block" size of its storage space), then write cached "pages" back to cleaned block together with those you intended to write initially. That's how NAND flash memory is functioning, simply.

All this "read whole block to cache (even if you need to change just one of 128 pages this block consist of) - clear block on drive - modify cached block - write it back" sequence repeated EVERY time you write something to "dirtied before" pages. So, degraded perfomance issue mostly stems from here - from the store you bring a new, fully CLEANed device; you write to it, delete, write again for a while; without TRIM, controller just ALWAYS when it possible tries to use FREE, CLEAN (NEVER used before) pages/blocks of storage space; AND, as I stated before, that doesn't mean "free" in terms of file system (file system counts space freed by deleting some file as free, for example), it means "never used before for anything"; this is when you expiriencing full speed of your SSD, when you need to write something, you just... write it instantly, in "page" size segments; then this time comes - you haven't got any "space never used before" anymore; and from that moment ANY write to disk you initiate will trigger aforementioned "read whole block to cache - clear block on drive - modify cached block - write it back" sequence, from that moment and FOREVER (or untill you force drive to fully CLEAN (i highlighted it to make accent - not just "delete all information" or "format" type of cleaning; NAND flash have special operation intended for such cleaning, and you need to force a controller to start it; TRIM force it to start it on specific blocks; without TRIM, AFAIK, some manufacturers developed special utilites for their drives, which can CLEAN all drive at once) it's "surface" and start from the clean list - if it has ability to do so; and will use TRIM supporting OS to prevent it happening again - because otherwise it will). This is root of perfomance degradation cause. And now is time for questions:

1) Here - http://forum.corsair.com/forums/showthread.php?t=85344 - and in some other thread by Corsair's employee we told that secure erase will restore perfomance of SSD. With all this theory above, can it be explained how exactly it will happen? Secure erase intended for cleaning a confidential data, so all it does is writing blocks of 0's or random garbage all over the drive surface; but, as we see from NAND flash working logic, that means nothing to SSD, because you don't force it to clean blocks to prepare them for writing withou overhead of caching-clening sequence, you just.. writing garbage to disk, its useless.

2) Here - http://forum.corsair.com/forums/showthread.php?t=97796 - we're told - by corsar employee - about some

"garbage collection" that is independent of the OS and runs at the controller level

How it can be realized at all? Does drive's controller understand.. NTFS, for example? Or, maybe, ext4? How it can make argumented descision to clean some block without knowing it's state in MFT table, or in inode table? I just can't get it, its impossible. This is why TRIM was introduced, as I understand, where OS "tells" the drive which "blocks" it allowed to CLEAN in a background garbage collection process. Because OS KNOWS, and drive controllers - DON'T

Can someone, preferably an manufacture representer, clarify these moments?

Link to comment
Share on other sites

In response to question 1: Your analysis of the situation is basically correct, with one small but highly important bit of information missing. It's true that writing zeros or any data to all the space in a SSD does not "secure erase" it, and is actually one of if not the absolute worst thing you could do to a SSD. To be clear, the desired affect of "secure erasing" a SSD, is setting all the NAND memory to it's "fresh" state, or really it's "ready to be written" to state. Writing anything to NAND memory does not put it into the fresh state.

 

The SATA command set contains a command called Secure Erase. It's initial purpose was to over-write data in a HDD, and cause it be unreadable in the future. But, any HDD or SDD does not directly execute SATA commands, a drives firmware is in part the interpretation layer between the SATA commands and what actually happens when a SATA command is received. While the SATA commands standards describe what the result of a command must (should) be, how a drives firmware accomplishes it is it's business only.

 

Fortunately, the SSD firmware programmers are not stupid, and have programmed their firmware to not write zeros to the NAND memory when a Secure Erase command is received, but perform a reset of the NAND memory to put it into the fresh/ready to be written to state.

 

The potential exists for a program that is designed to "erase" data from a HDD to not use the Secure Erase command, but just loop through all the LBAs in a disk and use SATA Write commands to write random data to the disk. We will hopefully know which programs do what I just described, or use the Secure Erase command. Personally, I will only use tools provided by the SSD manufacture to Secure Erase a SSD, or programs that the manufacture recommends for that purpose.

 

Regarding garbage collection in a SSD without TRIM, it exists, but the techniques used to accomplish it are a closely guarded secret by SSD controller manufactures, not surprisingly. I don't have the time, inclination, or knowledge to prove to you that it can work. IMO, that can only be proven or refuted with an intimate knowledge of the innermost workings of a SSD controller, and the actual low level details of the functioning of NAND data storage. All of that would be interesting to me but is not something that can be summed up in a few paragraphs. It is also something that IMO cannot be debated or discussed with any certainty by laymen, or the arm chair engineer.

Link to comment
Share on other sites

On garbage collection.

It is not such a witch-craft or wizardy as you might think. Just a technique to fill up whole blocks on the SSD with valid data and so coalesce free pages in single blocks. A picture says more that a log words.

 

attachment.php?attachmentid=10475

 

And thereby not dependent on the operating system. It is a low (block) level thing transparent to the OS or user. It might however cause infrequent delays. Garbage collecting is most likely to occur when the SSD is nearly full.

Garbage_Collection.png.463c90ae70e73afe4d04f6de270f54c4.png

Link to comment
Share on other sites

Mertvii, your 2nd is a very good question.

 

I am just speculating here- but as per the NTFS standard the MFT is stored on the same partition as the actual data. i.e. on the SSD NAND itself. This means that at least theoretically it would be possible for the controller to read the MFT and gain an understanding of the data structure... As the actual mechanism is a trade secret that would be my best guess.

Link to comment
Share on other sites

I've been questioning this myself after I read some articles written by at IT expert. Unfortunately I forgot the url.

He says "Secure Erase to restore performance" is actually an obsolete thing in the past. That was only true for 1st generation SSD where TRIM has not been introduced, which makes the SSD dirty with obsolete data after some time of use.

In fact TRIM is created to solve that problem in the first place, so it should never be done with newer generation SSD because it will only reduce their life unncessarily.

The only valid reason to SE with current generation SSDs is to clear confidential information inside the SSD, or when the problem can not be solved by ordinary measures (like zero writing hdd). The only thing needed to do to restore performance with current generation SSD is to let it sit idle for a while , so that garbage collection can work its magic without user intervention.

 

Frankly his explanation makes more sense to me.

Maybe people just got a little carried away with things in the past?

It's a common phenomena in PC OS.

If SE is a requirement, then shouldn't all SSD manufacturer attach a note of caution about this regular periodic maintenance?

In my case, I have used 3 Force 3 drive since 8 months ago, and I don't see any permanent /persistent degradation of performance at all, even after intensive writing & deleting huge chunks of data (in range of 15-20 GB). Sometimes I see a little performance loss after this, where boot time seems like 4-5 secs longer (according to Bootracer), but after idling for a while, everything recuperates itself so well that my next reboot is just as fast as before. ATTO & Crystaldiskmark number also confirm the self-recuperation.

Link to comment
Share on other sites

One thing that needs to be realized about SSD's (and flashram-based memory in general), is that you can never write zeros to it, you can only write ones. In order to rewrite a sector, you will need to send the reset command which automatically zeros all of that sector. You then write only the ones in the proper bit positions, while leaving untouched those bit positions that must remain zero.

 

This is quite different from what we're used to in hard disks, in which we have to set both the zeros and ones explicitly. This is the reason why TRIM was invented for SSD's, since the act of resetting the sector takes some comparatively large amount of time, they just leave the process of resetting the sectors for later in the background, so they can be done all at once, rather than one-by-one.

 

A Secure Erase would simply be resetting all of the sectors to zero simultaneously. Takes only a split second to Secure Erase, which is pretty fast in human time, but it may be pretty slow in computer time.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...