HDD GURU FORUMS

Good Morning Friends
I have got a NVMe SSD which is having proprietory encryption.
As per user he did nothing and suddenly laptop is not booting up,
In disk management disk shows all unallocated space but a ntfs partition is traceable .
However all sectors showed zeroed out.
What could be the reason ? A per customers IT they also did nothing and have put SSD in enclosure to copy data.
SSD might have been trimmed . Is there any specific auto erase mechanisam like SED drives in SSD too.

What do you see if you double-click New Volume?

BTW, one of your screenshots is showing the wrong NTFS boot sector. It should be 264192, not 264193.

New Volune seems suspect and likely the reason.

fzabkar wrote:What do you see if you double-click New Volume?

BTW, one of your screenshots is showing the wrong NTFS boot sector. It should be 264192, not 264193.

Thanks fzabkar as usual you have been very much helpful

New volume is empty. As per company CEO he just shut down laptop and when started next day boot device not found error pop up.
I suspect IT engineer has formatted (may be accidentally) this partition while doing expermentation.
But they are claiming innocence.

lcoughey wrote:New Volune seems suspect and likely the reason.

Thanks lcoughey
Yes you are right. MFT shows activities on 01.07.2023 . i think New Volume is created on 1st july.
Here is snapshot. Further all sectors are zeroed because of formatting
(trimming) ?

Not the formatting per se, (quick) formatting alone allows for recovery of data, it's TRIM that accompanies it that makes you read all zeros now. Someone there is telling you a half-arsed story

Over time, I have learned to take what users say as a reference rather than blindly believing everything they say. Relying solely on the user's words can be risky, as it leaves me vulnerable to potential harm. This is particularly true when I hear users confidently stating something as absolute truth.

Rudra wrote:As per user he did nothing
A per customers IT they also did nothing

Rule No#1 in data recovery, NEVER believe what the client tells you.

ddrecovery wrote:

Rudra wrote:As per user he did nothing
A per customers IT they also did nothing

Rule No#1 in data recovery, NEVER believe what the client tells you.

Well,
Never Never And Never

I'm not exactly sure why, but for some reason people seem to think that if they lie about not doing anything with the drive, it will somehow make it easier and cheaper to recover.

Thanks all of you for sharing vital knowledge. Appreciate all the efforts.

Arch Stanton wrote:Not the formatting per se, (quick) formatting alone allows for recovery of data, it's TRIM that accompanies it that makes you read all zeros now. Someone there is telling you a half-arsed story

Hi Arch
Thanks for explaning. I have few questions .
Sometimes I have recovered data after formatting from SSD's and sometimes not.May be trim was not enabled on those SSD's where data was recovered
On SSD's (all newer NVMe types) what triggers trim effect ?
1) Deleting file
2)Deleting Volume
3) Quick formatting
4)Deleting folder

In general it's the list you gave, deletions and (quick) formats where Windows sends TRIM commands.

There could be several reasons why it does not:

So, it's important to understand TRIM is a command, not actual erasure, that an OS or some tool can send to a drive. It allows the OS to tell the drive, I won't be needing LBA's in range x - y. So we need a command. ATA, NVMe, SD card specs all implemented TRIM like commands. But a USB flash drive for example not, so you can not send TRIM commands to it.

If we consider Windows, it only sends TRIM commands under a set of circumstances, one being TRIM needs to be enabled at OS level (fsutil behavior query DisableDeleteNotify), Windows will only send TRIM commands for NTFS and ReFS (not FAT32 or exFAT). So there's some reasons why Windows may not send a TRIM command.

I have also seen several situations where Windows paused TRIM commands because of file system inconsistencies: It wants to be absolutely that TRIM commands are really only send for clusters that are free, if there's doubts it seems it will pause 'trimming'. After chkdsk which took care of file system inconsistencies in those cases, Windows resumed trimming.

But so there's the OS. Some OS'es TRIM on a schedule and so there's room to recover data in between the deletion and the scheduled TRIM. Windows and does TRIM immediately and on a weekly I believe, schedule.

I'm not in-depth expert on sending TRIM commands at ATA or NVMe level, but I think they can be queued and for some reason they may be dropped from the queue, because there may be more pressing commands that need executing. Someone else may call BS on this, if so I welcome an explanation. May be the other way round as well if drive can not deal with queued commands and Windows itself drops TRIM commands due to more pressing matters. But idea is, loads of actual writes need to be done for example, and at some level it's decided "let's leave trimming for now".

Then there's the issue of for example drives behind a USB controller and this controller only supporting a sub set of commands and simply dropping commands it doesn't now. This has been an issue for quite a while with older USB enclosures and SATA to USB adapters. IOW the TRIM command never even makes it to the drive.

In general, as soon as the SSD receives the TRIM command it will remove access to the LBA sectors the TRIM command was for at translator level and return zeros if you try reading said LBA addresses even if data is not actually erased yet. This is the rule of thumb but a SSD may respond differently like return some random data.

Also, I seem recalling from some PDF ("the missing 'something' manual") that reverse engineered SSD firmware and that stated the SSD itself dropped TRIM commands if the LBA sectors weren't properly aligned somehow, but I'd have to look that up again before I consider this a solid statement. At the time it made some sense to me if we consider that actual erasure of the data can invoke overhead (drive has to consolidate stale pages in an erase block that it can actually erase) and some TRIM LBA range may not be aligned to pages or overlapping two partial pages, so that the SSD's firmware considers the efforts outweighs the gains. But unlike previous example, this would happen at firmware level and depends on the specific SSD.

Odds and bobs: If we talk about OS level factors, I believe at some point (or still) Linux kernel has a list of exclusions, of drives that will will not send TRIM commands to because these drives are believed not to correctly handle the command. Oh!, found it again:



Perhaps Windows maintains a similar list and perhaps list changes over time. This was the list at the time I screenshotted it, probably some years ago.

Anyway, there could be all kinds of reasons, and maybe more than ^ for TRIM not firing while we'd expect it to fire.

terminator2 wrote:Sometimes I have recovered data after formatting from SSD's and sometimes not.May be trim was not enabled on those SSD's where data was recovered
On SSD's (all newer NVMe types) what triggers trim effect ?

Mostly depends on the purpose of the SSD. Trim is enbaled by default on all slightly modern Operation Systems. On external SSDs it's not generally enabled.

Arch Stanton wrote:In general it's the list you gave, deletions and (quick) formats where Windows sends TRIM commands.

There could be several reasons why it does not:

So, it's important to understand TRIM is a command, not actual erasure, that an OS or some tool can send to a drive. It allows the OS to tell the drive, I won't be needing LBA's in range x - y. So we need a command. ATA, NVMe, SD card specs all implemented TRIM like commands. But a USB flash drive for example not, so you can not send TRIM commands to it.

If we consider Windows, it only sends TRIM commands under a set of circumstances, one being TRIM needs to be enabled at OS level (fsutil behavior query DisableDeleteNotify), Windows will only send TRIM commands for NTFS and ReFS (not FAT32 or exFAT). So there's some reasons why Windows may not send a TRIM command.

I have also seen several situations where Windows paused TRIM commands because of file system inconsistencies: It wants to be absolutely that TRIM commands are really only send for clusters that are free, if there's doubts it seems it will pause 'trimming'. After chkdsk which took care of file system inconsistencies in those cases, Windows resumed trimming.

But so there's the OS. Some OS'es TRIM on a schedule and so there's room to recover data in between the deletion and the scheduled TRIM. Windows and does TRIM immediately and on a weekly I believe, schedule.

I'm not in-depth expert on sending TRIM commands at ATA or NVMe level, but I think they can be queued and for some reason they may be dropped from the queue, because there may be more pressing commands that need executing. Someone else may call BS on this, if so I welcome an explanation. May be the other way round as well if drive can not deal with queued commands and Windows itself drops TRIM commands due to more pressing matters. But idea is, loads of actual writes need to be done for example, and at some level it's decided "let's leave trimming for now".

Then there's the issue of for example drives behind a USB controller and this controller only supporting a sub set of commands and simply dropping commands it doesn't now. This has been an issue for quite a while with older USB enclosures and SATA to USB adapters. IOW the TRIM command never even makes it to the drive.

In general, as soon as the SSD receives the TRIM command it will remove access to the LBA sectors the TRIM command was for at translator level and return zeros if you try reading said LBA addresses even if data is not actually erased yet. This is the rule of thumb but a SSD may respond differently like return some random data.

Also, I seem recalling from some PDF ("the missing 'something' manual") that reverse engineered SSD firmware and that stated the SSD itself dropped TRIM commands if the LBA sectors weren't properly aligned somehow, but I'd have to look that up again before I consider this a solid statement. At the time it made some sense to me if we consider that actual erasure of the data can invoke overhead (drive has to consolidate stale pages in an erase block that it can actually erase) and some TRIM LBA range may not be aligned to pages or overlapping two partial pages, so that the SSD's firmware considers the efforts outweighs the gains. But unlike previous example, this would happen at firmware level and depends on the specific SSD.

Odds and bobs: If we talk about OS level factors, I believe at some point (or still) Linux kernel has a list of exclusions, of drives that will will not send TRIM commands to because these drives are believed not to correctly handle the command. Oh!, found it again:

linux-trim-exceptions.jpg

Perhaps Windows maintains a similar list and perhaps list changes over time. This was the list at the time I screenshotted it, probably some years ago.

Anyway, there could be all kinds of reasons, and maybe more than ^ for TRIM not firing while we'd expect it to fire.

Wow what a Treat
The most comprehensive and detailed explanation on "Trim" . Thanks a lot Arch.
I have learnt so many things from this single post.
Trim is a command and OS issues it , I was of opinion that drives firmware has some role on it as I have read that FW recollects previous trim command and after reboot it destroys data on bios /hardware level.
I have also learnt that trim does not work for FAT /ExFat file systems .So is it advisable to have FAT32 partition instead of NTFS for internal OS SSD?
I think FAT 32 is pretty old and trade off might not be technically good ides just to escape from Trim. At least external SSD's are saved from wrath of trim.
Thanks again.

crashpcberlin wrote:

terminator2 wrote:Sometimes I have recovered data after formatting from SSD's and sometimes not.May be trim was not enabled on those SSD's where data was recovered
On SSD's (all newer NVMe types) what triggers trim effect ?

Mostly depends on the purpose of the SSD. Trim is enbaled by default on all slightly modern Operation Systems. On external SSDs it's not generally enabled.

Thanks a lot

terminator2 wrote:
Wow what a Treat
The most comprehensive and detailed explanation on "Trim" . Thanks a lot Arch.
I have learnt so many things from this single post.
Trim is a command and OS issues it , I was of opinion that drives firmware has some role on it as I have read that FW recollects previous trim command and after reboot it destroys data on bios /hardware level.
I have also learnt that trim does not work for FAT /ExFat file systems .So is it advisable to have FAT32 partition instead of NTFS for internal OS SSD?
I think FAT 32 is pretty old and trade off might not be technically good ides just to escape from Trim. At least external SSD's are saved from wrath of trim.
Thanks again.

Yes, TRIM commands are 'communication'.

Yes, firmware does have it's role. If we consider the OS the sender, the drive is the receiver and the firmware of the drive has to process the command. In general it will invalidate the LBA sector and set it aside for garbage collector which is another process ran by the firmware/controller. If we'd now read the sector the drive would just return a zero filled sector.
But on some old SSD the firmware my simply not recognize the TRIM command and respond with an error and do .. nothing. If we would read that 'trimmed' sector we can see it's contents.

With regards to FAT32/exFAT: It's not these file system have some inherent property that prevents TRIM, but as far as I'm aware Windows will not run TRIM on these file systems.

With regards to external drives: I believe the statement that external drives don't support TRIM is incorrect but I can see how some were led to believe so. First of all, the file system: I recon there's a better chance that an external drive is factory exFAT formatted rather than NTFS. And then we assume Windows will not send a TRIM command upon deletion etc..

A second factor is that a (USB) external drive introduces an additional layer where the command sent to the drive needs to be translated to an ATA / NVMe command and many older external drive enclosures / adapters didn't. IOW the TRIM command simply never reached the SSD behind this layer. So rather than sender (OS) and receiver (SSD) we're dealing with a middleman (USB adapter/enclosure) that needs to relay TRIM command from sender to receiver.

So these are two factors prevent TRIM and may have led people to believe that USB external SSD's do not support TRIM.

Many modern USB adapters etc. are perfectly able of relaying or passing through TRIM command and so an SSD behind such an adapter and formatted NTFS will be subject to TRIM. But you'd need to check with the manufacturer of the adapter or check specs to find out if their chipset supports it.

But the generic statement "USB external drive => No TRIM" is incorrect or at least an over-simplification as far as I know.

I also miss what 'purpose' has to do with anything, if we consider for a modern SSD TRIM is beneficial by definition regardless what the drive will be used for.

terminator2 wrote:

Arch Stanton wrote:In general it's the list you gave, deletions and (quick) formats where Windows sends TRIM commands.

There could be several reasons why it does not:

So, it's important to understand TRIM is a command, not actual erasure, that an OS or some tool can send to a drive. It allows the OS to tell the drive, I won't be needing LBA's in range x - y. So we need a command. ATA, NVMe, SD card specs all implemented TRIM like commands. But a USB flash drive for example not, so you can not send TRIM commands to it.

If we consider Windows, it only sends TRIM commands under a set of circumstances, one being TRIM needs to be enabled at OS level (fsutil behavior query DisableDeleteNotify), Windows will only send TRIM commands for NTFS and ReFS (not FAT32 or exFAT). So there's some reasons why Windows may not send a TRIM command.

I have also seen several situations where Windows paused TRIM commands because of file system inconsistencies: It wants to be absolutely that TRIM commands are really only send for clusters that are free, if there's doubts it seems it will pause 'trimming'. After chkdsk which took care of file system inconsistencies in those cases, Windows resumed trimming.

But so there's the OS. Some OS'es TRIM on a schedule and so there's room to recover data in between the deletion and the scheduled TRIM. Windows and does TRIM immediately and on a weekly I believe, schedule.

I'm not in-depth expert on sending TRIM commands at ATA or NVMe level, but I think they can be queued and for some reason they may be dropped from the queue, because there may be more pressing commands that need executing. Someone else may call BS on this, if so I welcome an explanation. May be the other way round as well if drive can not deal with queued commands and Windows itself drops TRIM commands due to more pressing matters. But idea is, loads of actual writes need to be done for example, and at some level it's decided "let's leave trimming for now".

Then there's the issue of for example drives behind a USB controller and this controller only supporting a sub set of commands and simply dropping commands it doesn't now. This has been an issue for quite a while with older USB enclosures and SATA to USB adapters. IOW the TRIM command never even makes it to the drive.

In general, as soon as the SSD receives the TRIM command it will remove access to the LBA sectors the TRIM command was for at translator level and return zeros if you try reading said LBA addresses even if data is not actually erased yet. This is the rule of thumb but a SSD may respond differently like return some random data.

Also, I seem recalling from some PDF ("the missing 'something' manual") that reverse engineered SSD firmware and that stated the SSD itself dropped TRIM commands if the LBA sectors weren't properly aligned somehow, but I'd have to look that up again before I consider this a solid statement. At the time it made some sense to me if we consider that actual erasure of the data can invoke overhead (drive has to consolidate stale pages in an erase block that it can actually erase) and some TRIM LBA range may not be aligned to pages or overlapping two partial pages, so that the SSD's firmware considers the efforts outweighs the gains. But unlike previous example, this would happen at firmware level and depends on the specific SSD.

Odds and bobs: If we talk about OS level factors, I believe at some point (or still) Linux kernel has a list of exclusions, of drives that will will not send TRIM commands to because these drives are believed not to correctly handle the command. Oh!, found it again:

linux-trim-exceptions.jpg

Perhaps Windows maintains a similar list and perhaps list changes over time. This was the list at the time I screenshotted it, probably some years ago.

Anyway, there could be all kinds of reasons, and maybe more than ^ for TRIM not firing while we'd expect it to fire.

Wow what a Treat
The most comprehensive and detailed explanation on "Trim" . Thanks a lot Arch.
I have learnt so many things from this single post.
Trim is a command and OS issues it , I was of opinion that drives firmware has some role on it as I have read that FW recollects previous trim command and after reboot it destroys data on bios /hardware level.
I have also learnt that trim does not work for FAT /ExFat file systems .So is it advisable to have FAT32 partition instead of NTFS for internal OS SSD?
I think FAT 32 is pretty old and trade off might not be technically good ides just to escape from Trim. At least external SSD's are saved from wrath of trim.
Thanks again.

Well,
ExFAT would be better ,FAT32 has a file size limit

I have also learnt that trim does not work for FAT /ExFat file systems .So is it advisable to have FAT32 partition instead of NTFS for internal OS SSD?

I missed this. My question would be why you'd not want TRIM?

Well,
ExFAT would be better ,FAT32 has a file size limit[/quote]
yes thanks Amarbir but I think ExFAT is suitable for external drives , for internal OS and data will it work