I'd like to have a statistic which shows how many of the trimmed blocks were waiting in the defer-write queue. This might give a good understanding at how beneficial the defer-write is for my SSD.
The possible performance I'd might get from the defer-write by rewriting blocks from the same page of the SSD chip at once instead of one-by-one is already solved by an SLC write cache Samsung provides for my 840EVO (patented as TurboWrite).
Seagate performs this too with their SSHD's.
Trimmed blocks in defer-write
Re: Trimmed blocks in defer-write
Ya, wouldn't be so hard since we already have "Deferred Blocks" which resets to 0 when timeout reached and we have "Trimmed Blocks" total.
We also would need to reset "Trimmed Blocks" to zero on defer-write timeout to receive "Trimmed Blocks per Defer"
So dividing the final count "Timmed Blocks per Defer" through the final count of "Deferred Blocks" before timeout (default 10sec) * 100 would result in Percentage of Defered-Trimmed-Blocks.
You can easy just call it "Trimm/Defer Hit Rate" and simply insert that actual value in the statistic-time-graph, same like "Cache Hit Rate", thus it would be more fluctuating depending on the task.
This vastly would show how synthetic write-benchmarks achieve so tremendous speeds on SSD, and still profit from Primo, reducing TRIMM overhead. xD
Good idea. +1
We also would need to reset "Trimmed Blocks" to zero on defer-write timeout to receive "Trimmed Blocks per Defer"
So dividing the final count "Timmed Blocks per Defer" through the final count of "Deferred Blocks" before timeout (default 10sec) * 100 would result in Percentage of Defered-Trimmed-Blocks.
You can easy just call it "Trimm/Defer Hit Rate" and simply insert that actual value in the statistic-time-graph, same like "Cache Hit Rate", thus it would be more fluctuating depending on the task.
This vastly would show how synthetic write-benchmarks achieve so tremendous speeds on SSD, and still profit from Primo, reducing TRIMM overhead. xD
Good idea. +1