Not happy with SSD free space cleaners

Hi,
I don't know about others but I am not happy, but I am gratefull for, the free space cleaners for SSD's. I've decided it looks simple enough so I'll try my hand at making my own with more of what I'd like to see and options I'd like to have.

Right now I'm using VB10 but it would be easy enough to port to VB with Dot Net 1.1

Any ideas for improvements on the old write FF's without any feed back, this is my main complaint. This is where I am now, just drive selection. I have it only selecting only fixed (HDD or SSD, not distinguishable yet) drives but think I should make an option for removable too.

A question for those running striped SSD Raids, would it be best to have an option to have, say 10%, of the fill be in the stripe size?

Now I'm a Noob to SSD's so suggestions are greatly appreciated, especially not reinventing the wheel ones. Sorry but I'd rather download than develop............

 

what is your goal here and what information are you using to decide on that goal?

Why do you want to toggle all of the bits in your SSDs?

 

Have to edit this after reading some white paper, those FF utils are not the real answer here forcing trim, have too rethink this.........................

Have to another edit; Now that the light has turned on I see so much better. If you understand how generally over provisioning truely works along with wear leveling and trim you can then understand that you should never ever use the system restore built into windows. Restoring to an earlier time is essentially a frontal attack on all of those algorithms. With the more advanced SSD's using compession and other tricks to enhance performance this becomes even that much more of a frontal attack.

Now I know why my drive never recovered after the restore until the secure erase. Along with this revelation fron end sleaners such as FF's is a trick but not a real answer. I am abandoning this idea, I am not even sure there is a real front end idea (file system level) that can do what I want at all.................

 

So are you trying to cheat the (firmware based) over-provisioning or add your own trim support to a drive/os/controller combo that doesn't support it or??

 

No I have trim. The problem with trim is it is great for deletes but as you over write files and the data then will reside in a new cell trim does not mark the old cell. The theory behind the FF writers is to the brute force place a write and delete on ALL cells that are free.

Researching over provisioning this is a problem. The file system mapped area can then really be any cells at any time. It dynamically moves all the time from the firmware and over provisioning, wear leveling, compression and other algorithms. So it is impossible to assume the cell, or group of cells you wanted to cover get covered by the brute force effect.

Now brute force will have to hit some of the files but there is no guaranty of 100% coverage but by averaging it has to get some of the drive. Of course it is a brute force so not too elegant. The advantage of using FF rather than 00 is MLC clean state is at FF. But this again doesn't mean the clean state of the MLC is at FF but the firmware would return 00 to the OS for that cell or take 00 as leaving the MLC cell at FF when it writes.

Optimally GC comes in during idle time and can clean up all nand currently over provisioned and then go to work on nand marked by trim. With the brute force effect to be most effective you would force trim on all mapped non over provisioned nand then let it still idle for GC to do its thing.

My idea with Raid0 was the small files can be on one drive or the other within the stripe but then again trim is not yet working on Raid0 so this is irrelevant right now. Other than maybe already having written the nand to FF state. The only problem then is the file system map could be anywhere in NAND on each independent drive so you yet again are chasing a rabbit blindfolded trying to chase down any particular NAND cell that may be dirty at the time.

So again I say, thanks but it isn't just what I thought then again I want to think on it some more...........

 

Still seems to me that you are trying to brute force yourself past the overprovisioning and wear leveling which are built into the drive firmware.

You might want to get in touch with the maker of your drive to see if they offer an SDK of some kind that would let you access the firmware at a level beyond the SATA interface.

Even conventional hard drives are 'overprovisioned' and use 'wear leveling' like SSDs do. It's not as extensive as with an SSD. Most people know it as the spare sectors/tracks used by the drive firmware to take care of the eventual bad sectors a conventional drive will develop.

Way Back When I was working disk array design for IBM and NetApp, we had access to firmware kits from IBM/HGST and Seagate. There is a lot you can do when you can access the hardware directly including using 100% of a drive available space leaving nothing for sector/track spares on individual drives.

When limited to what a standard SATA interface allows, not so much.

Drive firmware is intended to provide a pretty thick layer of virtualization between the mechanics/electronics of individual word/byte/bit storage on the drive media and the industry standard interfaces (SATA/ATA) and thusly the operating system drivers for the disk controller and file system. In this respect SSDs are no different than conventional HDDs.

Without the ability to talk past the firmware either by reflashing the drive with custom firmware or using a set of factory test rigs on the jtag (or equiv) connector, you might be stuck.