A longer stream of urgent writes should pause the cache Topic is solved

[Stubi]

I just copied files with many GB size to a disk that has a cache. Of course the cache was to small and so PrimoCache started to make urgent writes. But this slowed down the copy a lot. In addition all 8 CPU cores were very busy creating a lot of heat (a normal copy uses only 4 of them and not so much). Good that I saw this in time since I want to restore backups of many TB in the next days. Now I know it is better to switch off the cache for this.

I have no idea how PrimoCache is designed. Perhaps it writes into the cache first in such a situation and in the next step to the disk. If so would it not be better to stop the cache after a certain amount of urgent write blocks and pause the cache and write to the disk directly until the big data flow is over?

[InquiringMind]

Sounds like a good idea, assuming that pausing the cache in mid-copy can be done without risk of data loss. But a normal copy shouldn't exercise the CPU at all (disk write speeds limit what can be done and disk controllers should be doing most of that) unless you're using encryption. Care to mention what was causing the 4 core workout?

[Stubi]

This with the encryption is correct. The source disk had encryption and only the target disk had (write) cache active. But since there is only decryption and no encryption the work load for the CPU is not so high.

But even without encryption it is like this - I just tested it. Only some cores get used at a copy without cache (but not much - CPU load about 5 percent) and 8 cores are pretty busy with cache and urgent writes (CPU load about 70-80 percent). The write speed gets reduced to about 50-60 percent if the urgent writes start (copy from disk without cache to other disk with write cache and this time without any encryption). So that is a very big performance hit and resource usage if you have write intensive tasks.

[EricL]

The write speed gets reduced to about 50-60 percent if the urgent writes start (copy from disk without cache to other disk with write cache and this time without any encryption). So that is a very big performance hit and resource usage if you have write intensive tasks.

Sounds to me like you may have exposed a bug. Even with a lot of memory swapping, CPU usage should be constrained by the drive throughputs, so I wouldn't expect to see that kind of load. Perhaps there's some kind of polling or race condition going on between cache threads?

QB

[Stubi]

Just checked the problem with version 0.9.8 again. The problem seems to be solved in the meantime. PrimoCache did a perfect job with very little overhead compared to a normal copy when Urgent Writes set in.

Also instead of all 8 Cores only 4 Cores were used (this is the normal strategy if Win 7 32 Core Parking is active what is the Win 7 32 default. This Core Parking does not exist at Win XP. So do not wonder if all cores might be used there. I am not sure about Vista. But this change even came very late at Win 7 and should reduce heat and power consumption. It can be switched off).

[piquadrat]

As far as I understand 0.9.8 and 0.9.9 using L2 cache (ssd cache) only for reading. These versions delay syncing L2 cache to be more transparent. If you think about it, that seems logical. If you need high write iops, L1 with deffer writing is much much better solution then L2. On the other hand sequential write performance of today's platter based hard drives are high and comparable with SSDs. Besides longevity of L2 SSDs loaded with large sequential throughput comes to play.
So you observed no slowdown in large transfer to the cached volume because in 0.9.8 L2 is not used in this situation at all.

And in my tests PrimoCache is transparent to any encryption: truecrypt, diskcryptor included.