Romex Software Forum

InquiringMind wrote:support wrote:Ok, this issue raises from the design level. Both Total Write (Req) and Total Write (Done) are accurate. The root cause is that read cache and write cache share one tracing bitmap in order to reduce overhead and overload.In that case, doesn't it mean that the terms are improperly described? If the "Total Write (Done)" figure is affected by read activity, then it cannot accurately describe write activity.

These terms are correctly described the real write activities. It is because of the write amplification issue that "Total Write (Done)" may go beyond "Total Write (Req)", while write amplification issue is caused by the design of common tracing bitmap.

Well, thank you both for the response and candor. Just to be clear this something new in v2? I never noticed it in v1 and it still is not an issue on most of the machines I manage which often enjoy a 20-40% reduction in writes when Primocache is engaged. I realize workload and the variable make-up of cache contents are probably uncontrolable factors. But I do feel there are other influencers. That said, I don't want to speculate further without reproducable evidence. I have some tests in mind. Just have to find time to execute.

V1.0.1 has the same issue. Actually all PrimoCache versions have such problem. We used dedicated write tracing bitmap in FancyCache, but this design is not adopted in PrimoCache considering the overload and overhead as I said before.

Thanks for the explanation - disabling Write Caching does seem to eliminate the issue so may be a workaround for those concerned about the amplification effect.

I did notice PrimoCache offering a significant (nearly 2x) improvement on write speeds compared to FancyCache so this design feature does seem to help performance a lot, but the write overheads do seem to be significant (and presumably incur their own performance overhead) so I do hope a fix is found - even if it requires more memory overhead.

Follow-up: Over time write cache efficiency (my term) has returned to the levels seen in v1.0.1 with 4KB and 8KB block sizes. I continue to see write amplification with larger block sizes which did not occur on the previous version. I'm not sweating it as overall write activity is relatively low on the target systems. Is what it is. There are so many nice benefits to V2.x that rolling back is not even a consideration.

I'm a registered user and for me this topic isn't solved.
May be (or definitely) am I stupid.
But I understand nothing to your explanations.
My question is:
When I run the PrimoCache GUI, which value is the amount of datas really wrotten on the underlying volume with deffer-write enabled or not...?

"Total Write (Done)"

Sorry to come back to an old topic, but wouldn't using separate tracing bitmaps for read and write solve this problem? If that increases memory overhead significantly, then maybe have it as an option so users can choose between lower overheads or lower write amplification.

It is still not clear what is ACTUALLY happening.
Is the total write (Done) number WRONG. Or is it Correct?
On an SSD drive, when the computer requests, say 100 Meg be written, in fact 150 or 175 meg being written?
This is an SSD with a maximum write lifetime so it would be good to know.

If a request to write to a "block" for a small file, actually only writes say...200 bytes, then the disk block is (pseudo) 512 and the disk cluster is 4K, but all that should be written is the portion of the block that is requested...methinks and leave it up to drive controller.

If the softare is clever enough to figure out that my SSD has an erase block of 1 Megabyte (which I know) and then gathers writes of multiple 4K blocks into 1 Megabyte groupings (if they are adjacent)...that would be great.

Benediction wrote:It is still not clear what is ACTUALLY happening...

If Invisible Memory is being used, excess writes are being made - so the higher Write figure quoted is the correct one.

Benediction wrote:If a request to write to a "block" for a small file, actually only writes say...200 bytes, then the disk block is (pseudo) 512 and the disk cluster is 4K, but all that should be written is the portion of the block that is requested

PrimoCache works at block level, with the block size configured when setting up the cache - so if you have configured a 64K block size, then data will be written in 64K chunks. It has no awareness of an SSD's write block size or erase block size - the only way it can reduce writes is with Deferred Write with a long timeout (which can itself cause problems).