What to expect when using Recuva on an SSD c.f. HDD

[Alan_B]

My expectation is that there is little difference in capability with either so long as TRIM has not occurred.

e.g. no difference under XP or Vista.

 

My expectation is that on a TRIM capable system, Windows will issue TRIM after a file is deleted,

probably immediately upon deletion before Windows forgets what it has to do

I further expect that Windows and therefore Recuva will be kept totally ignorant of when TRIM has occurred,

and therefore Recuva will not know when or if a relevant page of NAND cells has been erased.

A further complication is that even if a file used consecutive LBA file clusters the SSD might write them to different pages of NAND cells,

and a "staggered" TRIM might result in some sections of data being erased before others.

I also suspect that some SSD products may possibly choose to refrain from reading back from any NAND cells that are subject to a pending TRIM.

 

Is my pessimism justified, or is RECUVA more clever than I thought ?

 

N.B. 64 bit Recuva v1.42.544 under Windows 7 Ultimate + SP1 with Trim active has found 30821 files in C:\ on my 60 GB OCZ Vertex 2 SSD.

Almost none of them are more than 1 kB (i.e. within 1 file cluster) and are reported as "No overwritten clusters are detected"

There are 4 files last modified 12/03/2012 which are 11 kB (using 3 file clusters) and are also reported as "No overwritten clusters are detected"

 

Is the Recuva verdict correct, or is it (as I suspect) being misinformed.

 

Regards

Alan

[Augeas]

From my understanding (and I'm no cleverer than the next idiot) Recuva, and all Piiriform's products, use the Windows API's to access the file system. So it doesn't access the storage device directly. Neither, of course, does Windows' file system NTFS.

 

The storage device is, in a delightful term, abstracted from the file system. To quote a very small part of a Raxco white paper, 'The Windows file systems know absolutely nothing about the configuration of the attached storage. ... The only thing the file system knows is what kind of partition it is and how big it is.'

 

So it's the file system that creates a logical map of the storage device, and all activity takes place against that logical map. For instance, NTFS will hold info in the MFT saying that a particular file occupies clusters say 10,000 to 10,003. You can edit and save this file a dozen times and the cluster allocation will stay the same as long as the file is not lengthened. Yet we know that a rewrite to an SSD involves writing the data to a new page and flagging the old page as invalid. You can check this with Recuva by running it in Advanced mode against a flash or SSD, selecting Show undeleted files, then chosing some innocent file to edit and save. Look at the cluster number in the info panel, it doesn't change. This is because the logical to physical mapping takes place in the SSD's controller. (It does in an HDD too, but that is a far more static mapping.)

 

The point of all this is that Recuva doesn't know or care about TRIM, and neither Recuva nor NTFS cares a hoot about what cells are erased. NTFS uses a pre-determined and unchanging set of cluster numbers to manage its files. It's a static view of the uiniverse. What the SSD does is its own business.

 

As you mentioned TRIM, I have a slightly different opinion of how it works. When an SSD page is edited and rewritten, the new data goes onto an unused page and the old page is marked as invalid. During idle time the SSD garbage collection module will consolidate valid pages into new blocks and empty the invalid pages for reuse. When NTFS deletes a file the page is not marked as invalid (in the NTFS world-view setting the bits in the cluster bitmap to 1 is enough) and thus avoids being cleaned up by the garbage collector. What TRIM does is tell the SSD to mark pages logically deleted by NTFS as invalid, so that the GC scoops them up. TRIM on its own does not delete or empty pages but updates the SSD's invalid page map.

 

So in the end Recuva is looking at the NTFS world, with bitmaps and everything in its place, a sort of Newtonion view. There's a whole parallel universe going on in the SSD, a sort of quantum mechanics view where nothing is quite where you expect it to be.

[Guest Keatah]

Newer SSD's, like the Samsung 830 series are NTFS aware and perform internal garbage collection and Trim-like operations based on information in the Metafiles.

[Augeas]

Yes, I've heard of some SSD's knowing that the file system is NTFS and thus knowing what pages are free and what aren't, but I haven't come across any deeper info yet. This wouldn't affect Recuva or Windows, as the device would still be at arm's length from the file system. Interesting stuff.

 

I've just run a quick search on Samsung 830 and can't find any reference of it being NTFS aware, even on the Samsung website (or any SSD being NTFS aware yet). It is pre-formatted as NTFS, but there are no other clues.

 

Hmm, a review of Samsung's Magician software shows a TRIM running against an 830 SSD. Is this what they mean by being NTFS aware?

[Alan_B]

perform internal garbage collection and Trim-like operations

Absolutely every SSD that was ever sold should have that capability.

Knowing almost nothing about modern SSD's, I am confident that :-

When the O.S. writes to a (virtual) Track Sector via an LBA that held a (Windows deleted) file then the SSD should remember if this data is still present in its NAND cells,

and if TRIM has not notified it then the SSD should automatically mark the current NAND cells for Garbage Collection and allocate new cells for new data being accessed by this same LBA.

 

SSD firmware needs a tremendous leap of intelligence to interpret from the metafiles which of the normal files have become garbage.

Question, how does the SSD know which of the metafiles have lost validity

 

The thought of an SSD knowing which files it can delete is comparable to a dog leading its walker toward its favorite lamp-post - over the road in-front of a high speed lorry.

[Augeas]

When the O.S. writes to a (virtual) Track Sector via an LBA that held a (Windows deleted) file then the SSD should remember if this data is still present in its NAND cells, and if TRIM has not notified it then the SSD should automatically mark the current NAND cells for Garbage Collection and allocate new cells for new data being accessed by this same LBA.

 

I thnk you are saying that if NTFS writes to a page containing old data then the SSD should write to a new page. That's exactly what does happen. If the page corresponding to the LBA/phys page mapping has not already been emptied and marked as available for writing, then a new available page will be used and the old page flagged as invalid. What happens to the LBA that pointed to the page that's been pinched? I dunno, probably there is a quantity of spare pages set aside for writing and the GC sorts them out later.

 

SSD firmware needs a tremendous leap of intelligence to interpret from the metafiles which of the normal files have become garbage. Question, how does the SSD know which of the metafiles have lost validity?

 

Yes, indeed. From what I remember the theory is that the SSD controller, knowing that the file system is NTFS, can access the cluster bitmap, check the free clusters in the bitmap against the corresponding pages, and mark those that aren't already free as invalid, ready for the good old GC (I simplify a little). It seems a huge leap of faith to me.

 

Here's a quote from an alleged Microsoft source, discussing Win 8.

 

'In Windows 8, when the Storage Optimizer (the new defrag tool) detects that the volume is mounted on an SSD - it sends a complete set of trim hints for the entire volume again - this is done at idle time and helps to allow for SSDs that were unable to cleanup earlier - a chance to react to these hints and cleanup and optimize for the best performance. We do not do a traditional defrag (moving files to optimize their location for space and performance) on SSDs.'

 

I think I'd rather trust this than a NTFS aware SSD.

 

(More info later) - You'll love this Alan. It appears that TRIM is not acctepted by RAID controllers. TRIM can be initialised, and TRIM commands passed to the RAID controller, with apparent success. However the RAID controller discards them as there is insufficient info to exceute them. TRIM enabled RAID controllers are just about on the horizon, though.

 

It's getting to the point where there are more NAND cells than I have brain cells, so getting a grasp of all this is difficult.