I notice in testing that using the cache in write only and with the option free cache on written it does not work exactly as you would expect.
Example: transfer large single file to system (lets say 100GB).
Let all the deferred blocks write out so it has written out of cache.
Now I go to read this file, you would expect that it would read from the drives and not from the cache but it reads from the cache.
I am not saying this is a problem, honestly it is a time saver but it is just an unexpected result from the user prospective.
This could trip up some users who want to do a file validation from the final destination and not from the cache to fully validate integrity post cache.
Free cache on written and write cache mode
Re: Free cache on written and write cache mode
When settiing the option "Free Cache on Written" a help popup appears and gives this info:
"If this checkbox is checked, when deferred write-date are written to the disk, cache blocks holding these data will be marked as standby blocks which will be discarded first if cache is full".
The option "Free Cache on Written" does not mean flush the cache when the contents of the cache are written to disk.
- The setting "Free Cache on Written" only means that as soon as cachememory is needed for some other write or read actions AND the cache is full this just used memory will be used -and thus cleared- as FIRST for new actions.
- So without "Free Cache on Written" activated then as soon as cachememory is needed for other write or read actions AND the cache is full the just used memory will be used -and thus cleared- as LAST for new actions.
So in real life I would say that if there is a high chance the just written data will be re-readed shortly then don't activate "Free Cache on Written".
And so if the chance is low that just written data will be re-readed shortly then activate the "Free Cache on Written".
-> But perhaps other people do have a different opinion about when activating this option "Free Cache on Written".
PrimoCache will handle the file validation and integrity if the disk that is cached is a disk from the PC that is running PrimoCache.
To my opinon you should not cache a network drive from you own PC. In that case use PrimoCache Server on the actual fileserver itself to maintain integrity for each file that may be used / modified by many users.
-> But perhaps other people have other / more knowledge.
I assumed that we talked about L1 cache. It MIGHT work the same for a L2 cache but I'm not sure.
Regards,
Bert
"If this checkbox is checked, when deferred write-date are written to the disk, cache blocks holding these data will be marked as standby blocks which will be discarded first if cache is full".
The option "Free Cache on Written" does not mean flush the cache when the contents of the cache are written to disk.
- The setting "Free Cache on Written" only means that as soon as cachememory is needed for some other write or read actions AND the cache is full this just used memory will be used -and thus cleared- as FIRST for new actions.
- So without "Free Cache on Written" activated then as soon as cachememory is needed for other write or read actions AND the cache is full the just used memory will be used -and thus cleared- as LAST for new actions.
So in real life I would say that if there is a high chance the just written data will be re-readed shortly then don't activate "Free Cache on Written".
And so if the chance is low that just written data will be re-readed shortly then activate the "Free Cache on Written".
-> But perhaps other people do have a different opinion about when activating this option "Free Cache on Written".
PrimoCache will handle the file validation and integrity if the disk that is cached is a disk from the PC that is running PrimoCache.
To my opinon you should not cache a network drive from you own PC. In that case use PrimoCache Server on the actual fileserver itself to maintain integrity for each file that may be used / modified by many users.
-> But perhaps other people have other / more knowledge.
I assumed that we talked about L1 cache. It MIGHT work the same for a L2 cache but I'm not sure.
Regards,
Bert
Last edited by EONDERDI on Sun Nov 18, 2018 4:31 pm, edited 1 time in total.
Re: Free cache on written and write cache mode
EONDERDI is right, "Free Cache on Written" does not mean flush and invalidate. If you want to do a file validation, just use "Reset Cache Content". See
http://www.romexsoftware.com/en-us/prim ... cache.html
http://www.romexsoftware.com/en-us/prim ... cache.html
Re: Free cache on written and write cache mode
Can you clarify this a little further...? Here is a much simplified scenario:
Say you have 8 blocks total in the L2 cache. At the start, all are empty. Then you write Blocks 1 & 2, a little while later 3 & 4, wait, 5 & 6, wait, then 7 & 8.
The waiting in this scenario is sufficient to ensure that PrimoCache has time to write all the data (two blocks in this case) to disk (even with deferred write).
Now the cache is full, and two additional block writes arrive. If I understand EONDERDI correctly, with "Free Cache on Written" checked, PrimoCache will clear and use blocks 7 & 8 first. Now after sufficient wait to allow a full write to disk, as an additional two block writes arrive, which ones will PrimoCache use for the new writes, etc.?
Now can you contrast the sequence when "Free Cache on Written" is not checked?
Thanks.
Say you have 8 blocks total in the L2 cache. At the start, all are empty. Then you write Blocks 1 & 2, a little while later 3 & 4, wait, 5 & 6, wait, then 7 & 8.
The waiting in this scenario is sufficient to ensure that PrimoCache has time to write all the data (two blocks in this case) to disk (even with deferred write).
Now the cache is full, and two additional block writes arrive. If I understand EONDERDI correctly, with "Free Cache on Written" checked, PrimoCache will clear and use blocks 7 & 8 first. Now after sufficient wait to allow a full write to disk, as an additional two block writes arrive, which ones will PrimoCache use for the new writes, etc.?
Now can you contrast the sequence when "Free Cache on Written" is not checked?
Thanks.
Re: Free cache on written and write cache mode
I corrected my response from nov. 15. I added "I assumed that we talked about L1 cache. It MIGHT work the same for a L2 cache but I'm not sure".
Regarding the message from mell111 on nov. 18, assuming L1 and L2 cache work the same way:
1. Mell's example saying: ".... and two additional block writes arrive ... with Free Cache on Written checked PrimoCache will clear and use blocks 7 & 8 first" the setting "Free Cache on Written" still means that if new data arrives -AND there is no more space- the most recent used blocks will be picked first, i.e. blocks 7 & 8 will be cleared and used FIRST.
2. This means that the contents of block 1 and 2 might be available in the L2 cache for a longer time.
If you would NOT have used free cache on written -AND there is no more space- then blocks 1 and 2 would be picked first with as result that block 7 & 8 could be available in the L2 cache for a longer time.
Althoug PrimoCache is talking about blocks, these are blocks from the source disk that is cached, meaning blocks from the original HDD when using a SSD as L2 cache. This just means that PrimoCache in this example just sends a delete to the SSD to for the space consumed what we in this example called "blocks 7 & 8" from the source disk followed by a new write. Similar as deleting a file manually with Windows Explorer from your SSD and then creating a new file. Especially with some unused space on your SSD the wear leveling will handle this, i.e. by no means the controller of your SSD will continue to use the same physical NAND cells over-and-over again.
Other topics in this forum do talk about the fact if TRIM is Yes/Not active when a L2 cache is used. Normally after sending a delete to a SSD it would be better to send a TRIM to inform the SSD controller. If there is no automatic TRIM send that may decrease your SSD life cycle.
Regards,
Bert
Regarding the message from mell111 on nov. 18, assuming L1 and L2 cache work the same way:
1. Mell's example saying: ".... and two additional block writes arrive ... with Free Cache on Written checked PrimoCache will clear and use blocks 7 & 8 first" the setting "Free Cache on Written" still means that if new data arrives -AND there is no more space- the most recent used blocks will be picked first, i.e. blocks 7 & 8 will be cleared and used FIRST.
2. This means that the contents of block 1 and 2 might be available in the L2 cache for a longer time.
If you would NOT have used free cache on written -AND there is no more space- then blocks 1 and 2 would be picked first with as result that block 7 & 8 could be available in the L2 cache for a longer time.
Althoug PrimoCache is talking about blocks, these are blocks from the source disk that is cached, meaning blocks from the original HDD when using a SSD as L2 cache. This just means that PrimoCache in this example just sends a delete to the SSD to for the space consumed what we in this example called "blocks 7 & 8" from the source disk followed by a new write. Similar as deleting a file manually with Windows Explorer from your SSD and then creating a new file. Especially with some unused space on your SSD the wear leveling will handle this, i.e. by no means the controller of your SSD will continue to use the same physical NAND cells over-and-over again.
Other topics in this forum do talk about the fact if TRIM is Yes/Not active when a L2 cache is used. Normally after sending a delete to a SSD it would be better to send a TRIM to inform the SSD controller. If there is no automatic TRIM send that may decrease your SSD life cycle.
Regards,
Bert
Last edited by EONDERDI on Mon Nov 19, 2018 3:27 am, edited 4 times in total.
Re: Free cache on written and write cache mode
Thanks, Bert. What I'm wondering, and is important to my use case, is whether in the above scenario, where PrimoCache has time to write every burst of data to disk before the next burst arrives, will it keep writing to the same blocks over and over or will it cycle through all of the blocks (whether newest first or oldest first.)
In the above example, the cache fills, is fully written out, then the new writes come in, two at a time: will 7 & 8 always get re-written (with 1 - 6) untouched, or will the order be 7 & 8, 5 & 6, 2 & 3, 1 & 2 in a cycle (or the reverse order without "Free Cache on Written"). I also wonder whether/how having a write-only cache affects this. With L1 cache the considerations are different because there is no concept of wear leveling as with an SSD in which with a lot of data to preserve even when no longer needed, the SSD will keep internally rewriting data over and over unless it detects that this data has been overwritten.
In the above example, the cache fills, is fully written out, then the new writes come in, two at a time: will 7 & 8 always get re-written (with 1 - 6) untouched, or will the order be 7 & 8, 5 & 6, 2 & 3, 1 & 2 in a cycle (or the reverse order without "Free Cache on Written"). I also wonder whether/how having a write-only cache affects this. With L1 cache the considerations are different because there is no concept of wear leveling as with an SSD in which with a lot of data to preserve even when no longer needed, the SSD will keep internally rewriting data over and over unless it detects that this data has been overwritten.
Re: Free cache on written and write cache mode
Pretty sure Primocache uses a FIFO queuing method (First In First Out) for the write cache. Whether it holds the data in the cache (in a read/write task scenario) is more up to frequency of use on the blocks and how much free cache is left.
Re: Free cache on written and write cache mode
I corrected my entry from "Sun Nov 18, 2018 4:52 pm".
My new info is also visible here but I corrected this in my original message to have no false information half way this thread.
<BEGIN NEW>
Althoug PrimoCache is talking about blocks, these are blocks from the source disk that is cached, meaning blocks from the original HDD when using a SSD as L2 cache. This just means that PrimoCache in this example just sends a delete to the SSD to for the space consumed what we in this example called "blocks 7 & 8" from the source disk followed by a new write. Similar as deleting a file manually with Windows Explorer from your SSD and then creating a new file. Especially with some unused space on your SSD the wear leveling will handle this, i.e. by no means the controller of your SSD will continue to use the same physical NAND cells over-and-over again.
Other topics in this forum do talk about the fact if TRIM is Yes/Not active when a L2 cache is used. Normally after sending a delete to a SSD it would be better to send a TRIM to inform the SSD controller. If there is no automatic TRIM send that may decrease your SSD life cycle.
<END NEW>
Perhaps someone from Romex could reply on this.
Regards,
Bert
My new info is also visible here but I corrected this in my original message to have no false information half way this thread.
<BEGIN NEW>
Althoug PrimoCache is talking about blocks, these are blocks from the source disk that is cached, meaning blocks from the original HDD when using a SSD as L2 cache. This just means that PrimoCache in this example just sends a delete to the SSD to for the space consumed what we in this example called "blocks 7 & 8" from the source disk followed by a new write. Similar as deleting a file manually with Windows Explorer from your SSD and then creating a new file. Especially with some unused space on your SSD the wear leveling will handle this, i.e. by no means the controller of your SSD will continue to use the same physical NAND cells over-and-over again.
Other topics in this forum do talk about the fact if TRIM is Yes/Not active when a L2 cache is used. Normally after sending a delete to a SSD it would be better to send a TRIM to inform the SSD controller. If there is no automatic TRIM send that may decrease your SSD life cycle.
<END NEW>
Perhaps someone from Romex could reply on this.
Regards,
Bert
Re: Free cache on written and write cache mode
Thanks Bert and Jaga. I'm sorry I didn't describe the scenario clearly enough.
While I obviously don't know the details of the PrimoCache algorithm, I'm sure it has to keep a logical map of the data elements it uses - whether block, sector, cluster or byte. I'm using block generically. It has to do this to know which element to release/preserve. While the SSD will determine which NAND cells to use as writes come in, and these will vary and move around without visibility to the OS, it will present to the OS a consistent logical map. It has to do this so that seek operations function properly.
Now, say PrimoCache for a particular use case wants to preserve as much old data as possible when the cache is full. It must do this by writing to the most recently used block(s) - enough to accommodate the size of the write burst. If each burst is only, say, one block and the bursts are spaced enough in time to allow the cache to be flushed, it would, in this scenario, always write to the same logical block (the most recent one written.) For RAM this isn't an issue at all. With SSD it very much can be (even with TRIM.) To do wear-leveling, the SSD will move data around, which generates internal writes that didn't originate from the host in addition to new host writes. This is one contribution to write amplification.
Now, for a read-write cache in certain use cases, there is no way around this and each user will decide the economics of SSD wear. There is no one ideal scenario. For write-only cache purposes, which PrimoCache helpfully supports and is very useful (at least for me) this is different because you are incurring a cost without a benefit (the read part of a read-write cache.) For heavy write volume that can add up and be significant.
Now, having said all that, after further reading the online help, I think I found a solution, which I will have to confirm: by issuing "clear cache" commands (that's in the CLI - I wonder if that's the same as "reset cache" in the GUI) often enough so that the cache never quite fills up, PrimoCache should then reuse the old blocks, which would signal to the SSD that those blocks don't need to be moved for wear leveling.
You may have seen my other post about a manual TRIM. If that scenario works, it should keep write amplification very low. I'll wait for Support's response before exploring this further.
Thanks again for responding - the information you provided was very helpful.
While I obviously don't know the details of the PrimoCache algorithm, I'm sure it has to keep a logical map of the data elements it uses - whether block, sector, cluster or byte. I'm using block generically. It has to do this to know which element to release/preserve. While the SSD will determine which NAND cells to use as writes come in, and these will vary and move around without visibility to the OS, it will present to the OS a consistent logical map. It has to do this so that seek operations function properly.
Now, say PrimoCache for a particular use case wants to preserve as much old data as possible when the cache is full. It must do this by writing to the most recently used block(s) - enough to accommodate the size of the write burst. If each burst is only, say, one block and the bursts are spaced enough in time to allow the cache to be flushed, it would, in this scenario, always write to the same logical block (the most recent one written.) For RAM this isn't an issue at all. With SSD it very much can be (even with TRIM.) To do wear-leveling, the SSD will move data around, which generates internal writes that didn't originate from the host in addition to new host writes. This is one contribution to write amplification.
Now, for a read-write cache in certain use cases, there is no way around this and each user will decide the economics of SSD wear. There is no one ideal scenario. For write-only cache purposes, which PrimoCache helpfully supports and is very useful (at least for me) this is different because you are incurring a cost without a benefit (the read part of a read-write cache.) For heavy write volume that can add up and be significant.
Now, having said all that, after further reading the online help, I think I found a solution, which I will have to confirm: by issuing "clear cache" commands (that's in the CLI - I wonder if that's the same as "reset cache" in the GUI) often enough so that the cache never quite fills up, PrimoCache should then reuse the old blocks, which would signal to the SSD that those blocks don't need to be moved for wear leveling.
You may have seen my other post about a manual TRIM. If that scenario works, it should keep write amplification very low. I'll wait for Support's response before exploring this further.
Thanks again for responding - the information you provided was very helpful.
Re: Free cache on written and write cache mode
A clarification - what Primocache calls a "block" isn't the same thing as a "cluster" on a formatted volume. A volume could have a 4k cluster format (minimum for NTFS), and Primocache's Cache Task could be set to use 16k blocks (as an example). Each of Primo's blocks would reference four volume clusters (a total of 16k contiguous space) in that sense. For best performance (but using the highest memory overhead) it is recommended to keep Primo's block size equal to volume cluster size. For volumes with lots of small files or small database records, keep the volume cluster size (and Primocache's blocks) small. For volumes with larger files, keep the volume cluster size (and Primocache's blocks) larger. You can mismatch them if you want (larger Primocache blocks than clusters), depending on your use. When using a L2, I would recommend matching block and cluster sizes between the two volumes. Primo's block size can't ever go lower than the volume's formatted cluster size, for obvious reasons.
Just wanted to offer that info, so that people don't get confused discussing how Primocache indexes and references volume/disk contents.
Support should be able to answer your concerns though. And I don't think TRIM is very far away at all, though even after it arrives I'd still over-provision any SSD used as a L2, for efficient garbage collection.
Just wanted to offer that info, so that people don't get confused discussing how Primocache indexes and references volume/disk contents.
Support should be able to answer your concerns though. And I don't think TRIM is very far away at all, though even after it arrives I'd still over-provision any SSD used as a L2, for efficient garbage collection.