Do SSD's make Recuva no longer necessary?

[rjo98]

Trying to get this straight in my head. With SSD's, they use TRIM to essentially wipe the spot a deleted file was at I think.  But if you run Recuva it gives a green light for a bunch of files on an SSD, and if you try to overwrite those it prompts you to skip it because you have an SSD.  So is Recuva no longer needed for SSD's?

[Augeas]

As far as I know, the TRIM commend flags a particular page or pages as invalid. This does two things:

 

1) The pages are unmapped from the lba to pba addressing table

2) When garbage collection is invoked internally by the SSD controller these pages are emptied and assigned to the available page pool.

 

If the file system sends a request to read the unmapped page then a default page of zeroes is returned. A page full of zeroes does not physically exist on SSD's.

 

If the file system sends a request to write to the unmapped page then a new page is assigned from the available page pool and the lba/pba addresses updated.

 

So Recuva is limited in what it can do. It can't retrieve a deleted page and thus asking to overwrite an unmapped page is meaningless. But Recuva can still be used to examine live files etc.

 

For TRIM to be effective it must be available and enabled on both the device and O/S. However TRIM is a wave goodbye command, there is no check that it has been, or will be, carried out. There are some circumstances when it is dropped, on some usb connected devices, or when the system is under stress, etc. So an occasional SSD Optimise would be a good idea, as this TRIM's the volume.

 

I should add that Recuva reads the MFT to retrieve a list of deleted files. The entries in the MFT still contain the cluster (lba) addresses. So although Recuva shows file names and cluster addresses the contents should be zeroes, as the addresses point to unmapped SSD pages. One use for Recuva is to check that this is so.

[Willy2]

- I think it's much simpler than that. I think RECUVA doesn't want to unnecessarily reduce the lifespan of a SSD by writing info to the SSD. RECUVA is primarily meant to recover deleted files.

- Where's that "available page pool" located ? On the flash drive as well ?

[Augeas]

I think it's actually far more complex than that. A few writes by Recuva won't reduce the life of an SSD by much, especially if one pass of zeroes is requested, as is essential.

 

The available page pool is managed by the SSD controller.

[Willy2]

Yes, I understand. But where is that pool located ? I would assume on the flash drive as well. Just like the same story with the MFT.

[Augeas]

As far as I know the available page pool is a mapping table that indicates which pages are available for reuse. It would be similar to a bitmap. Those pages identified in the table/bitmap form the available page pool.

 

On an SSD there would be a logical block to physical page mapping table, for translating the file system's requests from cluster number to SSD page; an invalid page pool which identifies which pages are to be erased by the garbage collector; and the available page pool which identifies which pages are ready for reuse. All these are internal to the SSD and cannot be seen by the file system.

 

When the O/S wants to write a cluster the file system sends the data with a logical cluster number to the SSD controller. The controller selects a page or pages from the available page pool, writes the data, and updates the lba to pba mapping table to assign the new pages to the logical cluster number. The pages previously assigned to the lba are allocated to the invalid page pool. When the garbage collector erases the invalid pages they are assigned to the available page pool.

 

I'm sure it's rather more sophisticated than that.

[rjo98]

I may be going a little off topic here from my original post, but how does the MFT flush itself of remnants of deleted files?  Is there a way to force it, so that way Recuva would return a much shorter list of files to look through?

[Augeas]

The MFT never reduces in size. When a file or folder is deleted its record in the MFT is flagged as such, never removed. It can be reused, so the MFT doesn't grow forever. The MFT uses relative record numbers to find its records, so no record can be safely removed.

 

Some software can fill the deleted records with files of zero length, and then ignore those when scanning (as Recuva can if the option is set). However the zero-byte records are still scanned, just not listed.

[rjo98]

Thanks.  I seem to remember ccleaner having a wipe mft option but it doesn't look like it's there anymore.  So a "wipe mft" is really the only way to get the file names references in the MFT to disappear so they don't show up for Recuva?  If so, how can you do that now that ccleaner won't anymore.

[Augeas]

CC Drive Wiper includes a wipe MFT, and the MFT can also be wiped under Wipe Free Space in Options/settings. Wiping the MFT is merely creating enough dummy or rubbish files to fill all the deleted file records, and then deleting them. Recuva will still show them, but they are of no value.

 

Recuva can't overwrite the file names in the MFT as it is a protected system file, which is why you have to create and delete files to get the same effect.

 

This is still relevant on SSD's as even though TRIM might remove the file's data clusters the record in the MFT is untouched (well, just flagged as deleted). Bear in mind though a wipe MFT on an SSD will involve rewriting the majority of the MFT, so a fair few new pages will be sucked up. Most entries in the MFT get overwritten in normal use over time, so I wouldn't run a wipe MFT very often on an SSD, if at all.