Page 1 of 1

123 PrimoCache43

Posted: Thu Jun 08, 2023 12:42 pm
by qweqwe321
PCache43 Win11 22H2

1. PCache43 - does not correctly detect "Windows Busy state" - defer wright start to wright to HDD only after "Latency" timer has run out.
2. Then Windows normally shutdown - PC power off BEFORE PCache43 will wright all deffer data to HDD. Because of it I get multiple Data damage. Questionable how PCache43 compatible with FastBoot (boot from state similar to Hibernation).
3. Compared to Win7 - Win11 tends to read a little more data from "FAT" area of logical Disks. Often Cache missing of 0.5-5 mb data happening. If HDD was already in sleep mode - got hangs while HDD will power on, and Windows will read this 0.5-5 mb of data. May be related to incorrect Windows Idle state detection - PCache43 start to fill L2 only after "Gather Interval" is ended (even if system is totally idle).
4. L2 checking (after unsafe Windows ShutDown) read only 1 HDD at time. NVME speed - allow to read multiple HDD simultaneously.
...
Another fundamental problems:
5. Even if I set "Gather Interval" = "INSTANT" - L2 (SSD) is still filled from HDD, not from L1 (RAM), not even from Windows MemoryCache.
6. Insanely big Memory Overhead: 13.51 GB for L2=347.46 Gb with block size = 4 kb.
If calculate 13.51 Gb/(347.46Gb/4kb) - it will be about 159 bytes of Overhead Data for every 4kb size block. Way too much as I think. Looks like someone don't use BitMaps, or use Maps with 64-bit size records for speed.

Re: 123 PrimoCache43

Posted: Thu Jun 08, 2023 2:27 pm
by TomB
1. PCache43 - does not correctly detect "Windows Busy state" - defer wright start to wright to HDD only after "Latency" timer has run out.
+1 - I seem to have this same problem if Write Mode is Intelligent or Buffer. Also, it mostly does not write until long after the percentage of write buffer is already filled (Buffer => 40%, Intelligent => 90%). Usually it will not write until buffer more than 100% filled. Sometimes more than 200%.

In fact, defer-write no longer seems to differentiate between Busy / Idle at all when Write Mode is Intelligent or Buffer. It seems to cause no difference even if I DO pick 'Ignore Windows Busy / Idle' or if I DON'T pick 'Ignore Windows Busy / Idle'. Appears to behave exactly the same way, if selected to 'Ignore Windows Busy / Idle' or not selected to 'Ignore Windows Busy / Idle'.

Further, if Write Mode is Intelligent or Buffer, then almost all writes to disk are always Urgent, never Normal.
2. Then Windows normally shutdown - PC power off BEFORE PCache43 will wright all deffer data to HDD. Because of it I get multiple Data damage.
Because I fear this, I always manually flush and pause Defer Write before shutting down computer.

Even with these issues, I still use PrimoCache every day and receive great value from it! Thank you again, Romex, for such a great piece of software.

Tom

Re: 123 PrimoCache43

Posted: Mon Jun 12, 2023 2:51 pm
by Support
qweqwe321 wrote: Thu Jun 08, 2023 12:42 pm 1. PCache43 - does not correctly detect "Windows Busy state" - defer wright start to wright to HDD only after "Latency" timer has run out.
Is the whole drive idle?
qweqwe321 wrote: Thu Jun 08, 2023 12:42 pm 2. Then Windows normally shutdown - PC power off BEFORE PCache43 will wright all deffer data to HDD. Because of it I get multiple Data damage. Questionable how PCache43 compatible with FastBoot (boot from state similar to Hibernation).

By design, PrimoCache will block Windows shutdown until it completes the flushing. If you have used v4.2.0, did this problem appear in v4.2.0?
qweqwe321 wrote: Thu Jun 08, 2023 12:42 pm 5. Even if I set "Gather Interval" = "INSTANT" - L2 (SSD) is still filled from HDD, not from L1 (RAM), not even from Windows MemoryCache.
PrimoCache will fill L2 from L1 if data still in the L1 cache. Windows memory cache is managed by Windows itself and it is located at file system level, PrimoCache cannot access its cached data.
qweqwe321 wrote: Thu Jun 08, 2023 12:42 pm 6. Insanely big Memory Overhead: 13.51 GB for L2=347.46 Gb with block size = 4 kb.
If calculate 13.51 Gb/(347.46Gb/4kb) - it will be about 159 bytes of Overhead Data for every 4kb size block. Way too much as I think. Looks like someone don't use BitMaps, or use Maps with 64-bit size records for speed.
Memory overhead is related to block size, cache size and target disk capacity. To reduce memory overhead, please try a bigger block size.