PrimoCache and TRIM command.

[idefix44]

PrimoCache knows wich L2Cache blocks are freed. to emulate the TRIM command would be a great feature...

[Support]

Thanks! Yes, we do have been implementing such feature.

[idefix44]

Thanks! Yes, we do have been implementing such feature.

I'm so sorry for my poor english but I haven't understand the quoted sentence.
Do you mean that the 1.0.1 version emulates the TRIM command or do you work on that for a next version?

[Support]

1.0.1 does not. We'll do it for future versions.

[idefix44]

Thanks.

[Chozo4]

Something like this would be a very welcomed addition.

Currently for TRIM support the following requirements must be met:
1) Host OS Support of TRIM
2) The drive being cached must be NTFS
3) Drive mode must be AHCI
4) The drive must support the TRIM capability.

In a large number of cases this will never be an option to reduce write count on the target systems. Many systems might either have one or the following with drives being cached and as a result will never see any TRIM capability unless it's supported through software in this case.

1) Host OS doesn't support trim (2000/XP/server 2003/etc)
2) Drives running in IDE-Mode over SATA, connected over PATA, PATA drives connected to SATA with adapter, or not over a SATA interface such as USB, SCSI,SAS, etc.
3) Drive doesn't support TRIM such as Compact Flash over SATA adapters, older SATA SSD drives, etc
4) Drives being used are not NTFS and instead FAT32, ExFat, or any other filesystem over a compatibility filter driver.

[Bjameson]

Personally I think L2 was meant to cache relatively persistent data, mainly to overcome the seek delay of spinning disks. When L1 and L2 are used together L1 handles the dynamic, constantly changing data and the less changing data goes to L2. This happens either by design or accidentally as 'spill-over' from L1. As such, true TRIM for L2 will not help much to speed things up. Without TRIM L2 blocks are erased just-in-time, instead of during SSD idle time.

L2 without L1 is a different matter. But even then, the common 80/20 rule applies. About 80% will be semi-static data and 20% dynamic. TRIM would make a difference, but far less than expected.

I think it's a good idea to always use L1 & L2 together. Even a small L1 with a short write delay will speed up things dramatically so that L2's lack of TRIM doesn't count so heavily. Also L1 has its own TRIM, which is nothing like the SSD-TRIM. Primo TRIM is a very efficient way of preventing redundant writes. it works independently of OS- or driver limitations. To take advantage of it, you must set a L1 write delay of 10 seconds or more.

[Chozo4]

Originally I had misread and missed the mention of L2 Trim in the OP and was assuming in the case of deferred write trimming. Couple with the fact it was confirmed a few posts back that Primocache currently does not emulate the trim command in its' write caching is why I felt my reply relevant.

Therefor I was speaking purely on the TRIM functionality of any writes waiting to be committed to the storage medium. Primocache only supports TRIM in the case of it being supported by the required statements mentioned before otherwise it will never trim write cache blocks and instead commit all writes regardless. I haven't seen any difference to this effect as the only 'trimming' you may be thinking of is in the case of deleting files and such removes it from the read cache instead.

I myself have deferred writes set to 'infinite' (which gets committed after 1 hour idle time) and have yet to notice deleted files ever reducing the value of deferred writes. Rather, the value increases due to adding another deferred write pending to set the timestamp and then the 'deleted flag' for the file instead. As a result it will still commit however many MB/GB of changes to a file before it applies the deletion flag afterward. Repeated writes to the same file even if it completely invalidates what was ever written prior will still remain in the write cache as well still waiting to be committed.

[Davey126]

I have not observed the behavior outline by Choz04 on L1 only configs with a 60s delay. In memory 'trims' occur regularly (at least as reported by PrimoCache GUI) for both deleted and overwritten files yielding a substantial reduction in the amount of data written to physical media over the course of a typical day. This is particularly noticeable with small print jobs where the output file is briefly spooled before being deleted. Also, I am not sure AHCI is a prerequisite. My general purpose desktop has an older SATA II mainboard that does not support AHCI. Trims work just fine using the integrated IDE interface. This may be MB specific. Certainly AHCI carries many other benefits and should be enabled/used whenever possible.

I am not shooting down the OPs request and/or other observations in this thread. Just adding my own experiences.

[idefix44]

My request isn't about the cached disk, but to emulate the trim command on the L2 Cache storage disk...