No flush cache on shutdown Topic is solved

[tbxn]

Miss function on 9.xx version is No flush cache on shutdown!

[CrypEd]

What you miss exactly?
Not beeing able to deactive this operational non-optional function?
So you missing the Risk (of the OS) loosing important data (for proper function)?

It always flushes cache on shutdown... what do you mean: No flush? For what??? Caring those upset-guys in the support-forum that killed there installation by that "no flush"?

There's no sense in NOT flushing cache on shutdown...this puts entire system at risk of permanently beeing broke with high likely having no chance to repair that mess at all!

Why do you want "no flush on shutdown"... tell one single reasonable thing that makes sense, please.

Now don't say: Faster shutdown...lol.

But if you not find a good argue, I am glad that this keeps as it is!

Flush Deferred Write-data
By default, deferred write-data stored in the cache will be flushed to disk at specified intervals, or when hibernating or shutting-down. However you can manually flush deferred write-data to disk whenever you want by clicking on the icon button in the command toolbar.

Source: http://www.romexsoftware.com/en-us/prim ... cache.html

So this amount is only the written data between the moment you want to shutdown and the moment of the last deferr-interval. I assume that you have a defferr-timeout of days/weeks and now want to quick-shutdown, what is no problem with normal deferr-timeout.... don't you wonder where your data goes from RAM after power-off: Unrecoverable Missing! So demanding a "no flush" on shutdown seems a little naive to me.

If you really want a fast shutdown and still using deferr-write...try to decrease the timeout. 10 seconds is perfect. 1 Day gives you a serious bunch of data to write on shutdown, unnessesarily.. plus that bunch of data is choking your Read-cache the hole day and "Not" writing such at the end of the day may kill your filesystem integrity instantly!

Probably you have to find out such on a different product than Romex!

BTW: You posted not a suggestion in the "suggestion"-subsection, wonder whats the sense in that at all. Plus their are plenty of users already in this forum asking for the same thing. SImply searching for "no flush" would have spared you the time asking. FYI: None of those guys had a single argue, except of "faster shutdown". lol. So next time you trying to "suggest" something, please try to "argue" at least: Why you want/need it!

[Support]

I understand that in some scenarios users may not need to flush deferred write data at shutdown. Option "No flush at shutdown" is available in FancyCache. However we removed this option in PrimoCache because this option will confuse most normal users. Such option may be enabled in CLI in future versions, but I'm not sure.

[CrypEd]

I really like to know such scenario just for informational reason...
what scenario for example?

It is not like i meant to sound unfriendly, but i just can not imagine in which case "no flush" is benificial.

If i would understand that, than maybe I see sense in that and join supporting the suggestion.

Yay, of course, CLI should be always the "alright" way to give (advanced-)users possibility to squeeze out every bit of performance and enhance customizability or .... to simply nuke their data doing the wrong things... critical options needs critical selection for critical tasks from intelligent users

[Support]

what scenario for example?

For eg. A write-protected system partition which all writes are re-directed to another partition. If caching on this system partition, there's no need to flush write data because all changes on this partition will be discarded after reboots.

[CrypEd]

A write-protected system partition which all writes are re-directed to another partition. If caching on this system partition, there's no need to flush write data because all changes on this partition will be discarded after reboots.

If something inside the OS (driver/app) is active that re-directs those writes of the write-protected system-partition to another partition... dont that one still need to receive all those re-directed writes of the write-protected partition, if you not flush how is it supposed to re-direct those possibly critical blocks.

So lets assume something on the app/os-level is writing onto another partition directly.... then nothing exists to flush on the device and invokking such command may be obsolete at all but no harm.

Anyhow If you say it's going to be re-directed then even on shutdown write data for the partition won't get discarded but re-directed... so flush is still needed.

If the devices driver really says "no write here", then probably there's no problem with Primo "trying" a flush... because it simply wont work for the device-partition.

Dont get the point.

Also why use "Deferr-write" at all on a "write-protected"-device... whats the argue here? Theres not only no need for "no flush" on write-protected partion, but no need for defer-write at all xD

I still see that IF using Deffer-Write THEN flushing those writes on shutdown should be NOT OPTIONAL, but always be the case, even if something is re-directing those writes on shutdown to another partition!

Not doing it is still packing all writes including critical ones of the system without a backup into a volatile storage (RAM) and then go straight ahead "plugin off the power-cord". If critical things need to be written/re-directed after your last timeout-intervall... thats all gone, and therefore possibly destructing system boot-process, system-services, runtimes, ntfs-file-system integrity and all kinds of stuff!

... not the best example, is there any other scenario to show the usefulness of such function "no flush on shutdown"?

All I'm saying is:
"You should not "not flush" on shutdown while using ram-cache!"
It's really dangerous!

"Always flush on shutdown." is what keeps the solutions integrity alive. The consequence of not doing it is a high risk of bluescreen and other malfunctions.

Im trying to understand the "other side" demanding such feature, no success

BTW: Im so what paniced, that while using 10secs defer-timeout, whenever I change critical windows system files or drivers.... i go inside the GUI and manually flush as soon as i can... lets say you've installed your nvidia driver and have 1 hour timeout...uhh i would go crazy by the risk power-loss could cripple my hole system graphics driver environment incl invoking of the drivers at boot, so risking bluescreen at boot! Im not a Fan of long timeouts... but no flush on shutdown is a ridiculous demand... other products completely failed because of NOT having that (proper flush on shutdown) working

[Support]

If something inside the OS (driver/app) is active that re-directs those writes of the write-protected system-partition to another partition... dont that one still need to receive all those re-directed writes of the write-protected partition, if you not flush how is it supposed to re-direct those possibly critical blocks.

Some users have a demand that systems work as normal during runtime but will be restored to the original one after reboot. That's why they need to redirect writes or keep write changes on ram and can discard such write changes at shutdown.

[i560ma]

i want the function of No flush cache on shutdown, it is very cool and fanny in the vhd system.

[i560ma]

If something inside the OS (driver/app) is active that re-directs those writes of the write-protected system-partition to another partition... dont that one still need to receive all those re-directed writes of the write-protected partition, if you not flush how is it supposed to re-direct those possibly critical blocks.

Some users have a demand that systems work as normal during runtime but will be restored to the original one after reboot. That's why they need to redirect writes or keep write changes on ram and can discard such write changes at shutdown.

Will No flush cache on shutdown occur on next version of primo cache???

[Support]

Added in v2.0.0. This option can be enabled through command-line.