TRIM on NVMe disk under WinXP

[George King]

@reboot12 There is really newer ported drivers collection here

 

 

[reboot12]

7 hours ago, reboot12 said:

I am only thinking about one thing - why I can't use a small text file for the test - a few bytes ???

I already know the answer to this question.

Small text file is located in $MFT record and not occupied any cluster - that's why TRIM has no access to it.

[reboot12]

2 hours ago, George King said:

There is really newer ported drivers collection here

Thanks but I checked these drivers and there are still the same problems as in the August version:

• Samsung_NVMe_3.3.0.2003 - error while installation in .inf file
  
• Generic_NVMe_10.4.49.0 - after restart WinXP SP2 x64 not boot - probably BSOD

Of course, it's about x64 versions !

Edited December 10, 2022 by reboot12

[Andalu]

@reboot12

Regarding the Samsung NVMe 3.3.0.2003 driver, the secnvme.inf file must be modified to recognize non-Samsung generic NVMe drives.

The Generic NVMe 10.4.49.0 driver works correctly on XP 32 bit. I have never tried the x64 version.

[Andalu]

Still according to what is reported by TrimCheck, the Naraeon tool appears to perform trim for NVMe drives as well. Tested with MS and Samsung drivers.

Below are images with the Samsung driver (here working even without secnvmeF.sys):

before trim:

running trim:

after trim:

 

I have not yet verified what the "semi-automatic trim" option consists of.

[reboot12]

11 minutes ago, Andalu said:

Regarding the Samsung NVMe 3.3.0.2003 driver, the secnvme.inf file must be modified to recognize non-Samsung generic NVMe drives.

I have a Samsung 970 EVO Plus disk and the secnvme.inf file is appropriate PCI VEN DEV

However, I looked at file and it looks like there are simply mistakes:

[SourceDisksFiles.amd64] should be probably [SourceDisksFiles.NTamd64]

[nvme_inst.NTx86.CopyFiles] should be probably [nvme_inst.NTamd64.CopyFiles]

18 minutes ago, Andalu said:

Below are images with the Samsung driver (here working even without secnvmeF.sys):

I don't understand why you are running the TrimCheck program 3 times? All you need is 2 times! During the first launch, the program creates a trimcheck.bin file on the disk, saves its location and a few bytes of data in the .json file and then deletes the trimcheck.bin file and then informs the user to now make a manual trim so you do TRIM, e.g. in O&O Defrag. After TRIM You run TrimCheck again, which compares the data contained in the .json file with data in the disk cluster.

[Andalu]

@reboot12

I have executed TrimCheck twice even though there are three images I posted. The second one (running trim) is just to show the scroll bar of O&O and Naraeon indicating that trim is running.

Regarding the Samsung v3.3.0.2003 driver, I thought you were using a non-Samsung model.

[George King]

2 hours ago, reboot12 said:

I have a Samsung 970 EVO Plus disk and the secnvme.inf file is appropriate PCI VEN DEV

However, I looked at file and it looks like there are simply mistakes:

[SourceDisksFiles.amd64] should be probably [SourceDisksFiles.NTamd64]

[nvme_inst.NTx86.CopyFiles] should be probably [nvme_inst.NTamd64.CopyFiles]

[nvme_inst.NTx86.CopyFiles] should be probably [nvme_inst.NTamd64.CopyFiles] is true, then it should work.

[jaclaz]

16 hours ago, reboot12 said:

I already know the answer to this question.

Small text file is located in $MFT record and not occupied any cluster - that's why TRIM has no access to it.

Only for the record the limit for a file in $MFT is around 750 bytes on 512 bytes sector ($MFT record sized 1Kb) and around 3800 on 4K sectors ($MFT entry sized 4Kb), exact values here:

https://www.forensicfocus.com/forums/general/mft-resident-data/paged/2/

jaclaz

 

[reboot12]

@George King

• I have fixed the secnvme.inf x64 file and works without any problems including TRIM in O&O Defrag
  secnvme_fix_by_Gelip.zip
  
• Silicon Motion Generic_NVMe_10.4.49.0 works only because I updated the driver when the Samsung driver operated - it is exactly about the secnvmeF service running. After switching off the service:
  sc config secnvmeF start= disabled
  I turned on the Windows debug through the serial port in BCD and after restart OS I have a 7B error in WinDbg:
  WinDbg 7B error log
• SmartDefrag 4.2 and TxBENCH 0.98 not make TRIM on any driver
• O&O Defrag make TRIM on Generic_NVMe_6.1.7601.23403, fixed_Samsung_NVMe_3.3.0.2003 and Silicon Motion Generic_NVMe_10.4.49.0 with secnvmeF service running (from Samsung driver)

Edited December 11, 2022 by reboot12

[George King]

@reboot12 Your SourceDiskFiles section is not correct according to documentation.

https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-sourcedisksfiles-section

	[SourceDisksFiles] | 
[SourceDisksFiles.x86] | 
[SourceDisksFiles.ia64] | (Windows XP and later versions of Windows)
[SourceDisksFiles.amd64] | (Windows XP and later versions of Windows)
[SourceDisksFiles.arm] | (Windows 8 and later versions of Windows)
[SourceDisksFiles.arm64] (Windows 10 version 1709 and later versions of Windows)
	

[reboot12]

@George King

OK, SourceDisksFiles.amd64 but I corrected the rest of the mistakes well.

[reboot12]

@George King

I have a question? Before installing the NVMe 1.3 driver by Schtrom installed the WindowsServer2003.WindowsXP-KB932755-x64-ENU.exe update that updates files: storport.sys and diskdump.sys

Then I updated the NVMe driver for a corrected Samsung_NVMe_3.3.0.2003 which probably replaced the storport.sys file. The diskdump.sys file was remained from the KB ...755 update.

Will NVMe drivers work properly without an updated diskdump.sys file?

[mockingbird]

Thanks for this thread...  I never trimmed my drive since installing XP, and I always thought this was something I would have to do manually by booting linux on a USB thumb drive one day...  And I kept procrastinating.

Naraeron did not launch originally with the generic NVME SCSI adapter, so I installed the backported Samsung adapter, and it does open (but throws an error before opening: "entry not found with id -241") and TRIMs the drive fine.

Write performance has also improved.

 

Before:

After

I approve

[reboot12]

From what I found out, the diskdump.sys file is used when BSOD appears in the OS - then debugging information is saved on the disk in %SystemRoot%\Minidump

I found the update of the diskdump.sys file for Win7 without which during saving debugging information may be damaged volume on disk if is larger than 2 terabytes:

One or more volumes are corrupted on a hard disk when a dump file is saved on a computer that is running Windows 7 or Windows Server 2008 R2 if the hard disk space is larger than 2 terabytes

My NVMe disk is 250 GB so I don't think these updates are needed.