Manual TRIM as Stopgap
Posted: Sat Nov 17, 2018 10:38 pm
While we await the possible addition of TRIM support in PrimoCache, I was wondering what would be the most expedient way to make use of the manual TRIM option Windows provides (via Optimize Disks).
Would it be sufficient to stop the cache task associated with a given SSD acting as L2, reset the cache (which hopefully would invalidate the data, which, again hopefully, would have already been flushed when stopped) and then issue the TRIM via Windows Optimize (manually). For this to work, the following would be required:
1. The L2 cache partition filesystem would need to be known to Windows (in Disk Management). I realize that PrimoCache implements its own "volume" in the partition, but I'm not sure if that is done via a Windows filesystem or is invisible to Windows at the filesystem level. If it's invisible to Windows, this approach won't work because the TRIM would tell the SSD that the partition is completely empty except for the data that is also visible to Windows.
2. There can be no PrimoCache data left in the relevant SSD partition after the cache stop and reset that Windows doesn't know about (in the Windows filesystem, if any). Here too, any PrimoCache data invisible to Windows is a show stopper because the TRIM would lead the SSD to consider the partition totally empty except for the data that is also visible to Windows.
If the above won't work, there is always the alternative of removing the relevant L2 cache altogether in PrimoCache, issuing the TRIM and then recreating the cache task. That is only practical if the process can be scripted (for me at least.) So, does PrimoCache command-line interface support the creation and removal of cache tasks with all of the options available through the GUI? If so, does it looks like this should work? Is there anything I may be missing?
In case anyone is wondering, the use case here is heavy write activity with significant potential for write amplification (which can get prohibitive with the most commonly available TLC SSDs available these days at the lowest prices.) While relying on spare SSD capacity in combination with built-in garbage collection is certainly helpful (thanks to Jaga for mentioning that), this does not address the issue of flushed and invalidated data that the SSD would still think is valid and would move around for purposes of wear-leveling.
Thanks.
Would it be sufficient to stop the cache task associated with a given SSD acting as L2, reset the cache (which hopefully would invalidate the data, which, again hopefully, would have already been flushed when stopped) and then issue the TRIM via Windows Optimize (manually). For this to work, the following would be required:
1. The L2 cache partition filesystem would need to be known to Windows (in Disk Management). I realize that PrimoCache implements its own "volume" in the partition, but I'm not sure if that is done via a Windows filesystem or is invisible to Windows at the filesystem level. If it's invisible to Windows, this approach won't work because the TRIM would tell the SSD that the partition is completely empty except for the data that is also visible to Windows.
2. There can be no PrimoCache data left in the relevant SSD partition after the cache stop and reset that Windows doesn't know about (in the Windows filesystem, if any). Here too, any PrimoCache data invisible to Windows is a show stopper because the TRIM would lead the SSD to consider the partition totally empty except for the data that is also visible to Windows.
If the above won't work, there is always the alternative of removing the relevant L2 cache altogether in PrimoCache, issuing the TRIM and then recreating the cache task. That is only practical if the process can be scripted (for me at least.) So, does PrimoCache command-line interface support the creation and removal of cache tasks with all of the options available through the GUI? If so, does it looks like this should work? Is there anything I may be missing?
In case anyone is wondering, the use case here is heavy write activity with significant potential for write amplification (which can get prohibitive with the most commonly available TLC SSDs available these days at the lowest prices.) While relying on spare SSD capacity in combination with built-in garbage collection is certainly helpful (thanks to Jaga for mentioning that), this does not address the issue of flushed and invalidated data that the SSD would still think is valid and would move around for purposes of wear-leveling.
Thanks.