Is using Secure file deletion on SSDs with TRIM pointless or not?

[ukine]

I've done the requisite googling and searching on the forums themselves and I did not find any up to date information on whether using Secure file deletion (Simple overwrite 1 pass, wipe alternate data streams, wipe cluster tips) actually overwrites the files and information on a TRIM enabled SSD under Win7/NTFS before deleting the files or if it just orphans the cells taken up by the files and initializes other cells (effectively negating the idea of secure deletion and producing more wear on a TRIM enabled SSD under Win7/NTFS).

 

Does anybody know which scenario happens, or if it might be different from my two ideas on how it happens?

 

Thanks,

Dan

[Alan_B]

I guess that when you THINK you are over-writing an unwanted 1 MB then the SSD controller will actually over-write 1 MB of fresh cells,

and the unwanted 1 MB file will survive until TRIM tells the controller to erase the corresponding cells.

I further guess that is is possible that Windows may fail to issue any TRIM to erase the 1 MB over-write,

and that is garbage that will never be collected,

and the pool of available erased cells will go down the drain.

[Augeas]

To the best of my knowledge - and I make no claims about the capability of my brain or the scope of my knowledge - the following is true on a modern SSD:

 

The logical clusters - what you, I, the file system, and every man and his dog will ever see - are mapped to the SSD's physical blocks by lba mapping tables in the SSD. You can never see or access the physical blocks directly.

 

When a file delete is issued by the file system on a TRIM enabled SSD the relevant logical clusters are unmapped from the mapping tables. The associated physical blocks are marked as invalid and are erased later by the SSD's garbage collector and returned to the pool of available blocks.

 

When an empty cluster (all zeroes) is written to the SSD - as in CC's one pass overwrite - the relevant logical cluster is simply unmapped from the mapping tables. The associated physical blocks are marked as invalid and are erased later by the SSD's garbage collector and returned to the pool of available blocks.

 

In the lba mapping tables the only actual logical cluster to physical block mapping is for blocks with non-zero data. All empty clusters, or clusters containing zeroes, are unmapped. When a request is made to read an unmapped cluster a default cluster of zeroes is returned to the file system. This resolves the SSD conundrum: if an erased block on a SSD is one initialised to all ones - as it is - why do we see all zeroes when we read it?

 

So my opinion is that on a TRIM enabled SSD CC's secure delete is unnecessary, a normal delete does just the same thing. On a non-TRIM enabled SSD CC's secure delete, and WFS, can be useful. There was quite a lot of discussion a few years ago about CC's WFS restoring speed to an SSD. I think that was the beneficial effect of writing clusters of zeroes to an SSD without TRIM.

 

It is not possible to overwrite (securely delete) a block on an SSD. TRIM will free the block and garbage collection will erase it, doing the job for you. Or use CC's secure delete or WFS on an old un-TRIM'd SSD.

 

I have to say that controller software is highly protected by the SSD manufacturers, and what actually happens inside the SSD is not publicised. All this is what I've picked up from many sources. And in doing so I have changed my opinion from never use WFS on an SSD to well, maybe.

 

Oh yes, never ever use anything other than CC's one pass of Zeroes, otherwise all this is out of the window.