Data Recovery Weekly

If you delete a Storage Spaces pool on a TRIM-capable SSDs, the entire pool gets trimmed, as in poof!, gone .

It is known that filesystems that you will probably use on Storage Spaces, namely NTFS and ReFS, support TRIM . We have no information about FAT but it is unlikely that someone will use FAT in conjunction with Storage Spaces. So, if you delete a file on a volume located on a virtual Storage Spaces disk, the filesystem driver sends a TRIM command to the Storage Spaces driver. The latter uses the same mechanism as TRIM uses in order to free slabs , i.e. to return slabs that are marked as unused by the filesystem to the pool of free slabs. Returning slabs to the pool of free slabs will take place if: a file being deleted fully occupies one or several slabs; a file being deleted is a single file in the slab meaning that after its deletion this slab would contain no data at all. Once a slab is withdrawn back to the pool of free slabs, it is impossible to easily identify the slab - what volume it belonged to, what location it had in the volume. Therefore, regular data recovery...

On NTFS, the process of file deletion is not limited by only the work of the file system driver such as zero filling pointers in MFT . Physical or virtual store takes part in this process as well. The filesystem driver sends a TRIM command to the store driver informing a data storage device that the blocks containing file data are not used any longer and therefore can be erased. Depending on the type of underlying device, TRIM can lead to different results: for a volume located on a regular hard drive, TRIM has no effect; for a volume created in Storage Spaces, TRIM leads to unexpected consequences depending on how the files are located in relation to 256 MB slabs of Storage Spaces; for an SSD, exactly for which the TRIM command was introduced, the blocks that are no longer in use are erased immediately. However, it should be noted that NTFS never frees blocks with metadata and so the NTFS filesystem driver never sends the TRIM command to erase these blocks. This NT...

Reading the article on NTCompatible as they test data recovery software and fail to recover data from TRIM-enabled SSD (which is pretty much the expected behavior), I see they're a little bit puzzled because some data would still remain even on a TRIM-enabled SSD. Interestingly, some traces to specific data remained, and that's one oddity I don't quite understand. The answer is actually pertty simple - these were NTFS resident files. On NTFS, when the file is deleted, its MFT record is marked "free, available for reuse", but never actually relinquished back to the free space. Because NTFS uses MFT entry numbers internally to address a parent-child relationships. Removing one entry would require an entire volume to be reunmbered, which is cost-prohibitve. So, the data outside MFT is zero-filled immediately once TRIM command is issued. The MFT entires however remain unchanged. This explains they were able to get file names and correct file sizes, but the dat...

TRIM wins. The TRIM command available on modern SSD reduces the chances to successfully undelete a file. TRIM violates the most significant principle of the data recovery that “the data is not overwritten until the disk space is actually required to store another piece of data”. Writing on a SSD is slower because before writing something to the block, it's needed to erase this block, and the erase operation is relatively slow. This is responsible for the performance degradation effect of the SSD when the performance starts to degrade as the device is filled to capacity, because there are no more blank blocks on the SSD. To compensate for this performance degradation, a hardware command TRIM was implemented to erase the specified blocks in advance. TRIM is supported by most modern high capacity SSDs. TRIM is commanded by the OS (supported starting with Windows 7). When Windows 7 is in the idle state, it commands TRIM to erase those blocks which are not in use any longer. TRIM violat...