Function : No Write-Flush on Shutdwon

Suggestions around PrimoCache
Post Reply
tbxn
Level 1
Level 1
Posts: 3
Joined: Sat Sep 21, 2013 6:54 pm

Function : No Write-Flush on Shutdwon

Post by tbxn »

On version 0.8 (fancycache) : the No Write-Flush on Shutdown is the most function i love,
But on version 0.9 (primocache) no way to find this
Please update on the next
Thank you so much
Incriminated
Level 6
Level 6
Posts: 65
Joined: Fri May 31, 2013 3:03 pm

Re: Function : No Write-Flush on Shutdwon

Post by Incriminated »

Please provide the use case in which no-write-flush on shutdown makes sense.

When you shut down your computer, on most hardware which usually contain nonpermanent RAM, this is neccesary to prevent data-loss in write-cache configuration +defer-write.

Extreme large defer-write timeouts do not make your system faster... contary, lets say you have a 4GiB L1 and you set your defer-write timeout to 1 day. During normal use, without any special write task, a PC takes some time to cache 4Gib, lets say 12 hours. So after 12 hours your cache is nearly full and 3,9GiB waiting senseless in cache to be written onto disk. To defer-write does not mean clean it from cache. It only means the data is written to disk after a certain timeout. But it should stay in cache until the moment your cache-strategies-algorythm needs to free some space. So the problem now is when your cache is nearly full, your disk is bored and sudddenly you want to read or write a complete different file. PrimoCache has to free up cache-amount, so the new data fits and is ready to be loaded into the L1, to accomplish that it starts freeing up space, by selecting "old" data by algorythm and writing it all down to disk. This is where your "new" read/writing-Tasks gets slow as hell, because it can only mark the RAM as free, when the data is savely written onto disk, so it waits until thats finished. This would not happen, when you keep the defer-write timeout low, so PrimoCashe starts flushing as early as possible WHILE still keeping the data in L1 for faster later use. The only difference in that situation now is, that the algorythm can free "old" data from L1 without writing it (nearly instant), because it is already written and your new task always start at full cache-performance.

The reason that you have to configure a defer-write-timeout at all is that an instant write may decrease RAM-performance a little (by the factor of disk-write, which is minor) because of shared I/O, but within 10 seconds it could write my hole 16GB-RAM and read from it.... plenty times. The bottleneck is the disk-write-rate, so you would want it keep away from that bottleneck and not forcing to run into it. The Cache is dependent on that bottleneck while flushing, so at best you would start defer-writing as soon as the write-task on RAM-side is done. Whatever the disk does in the background to defer-writes fast and ongoing only consumes a minimum of CPU-Bandwith (nearly none thanks to DMA), what is not affecting your system performance at all, since "your disk" is "PrimoCache" and not "the disk itself". When the disk is full busy defering a big write, that does not decrease your system performance, as long as the cache is free... contrary to a long defer-write timeout, where it starts flushing full lcache on access. This especially comes in handy with R/W-Cache ;)

In short:

with long timeouts you make all disk-writes peak exactly at the moment, that your Cache is full, which is exactly the moment you would need the performance hardly. then it's again full and dont start flushing, until you trying to write new stuff, so this will constantly bottleneck your system down to disk-write-speed.

with short timeouts you make the disk-writes always run in the background, so PrimoCache can clear the hole space allocated in defered-writes instantly and always boost good performance. this is essential for PrimoCache to function properly.

The only reasons that i see long defer-write timeout make sense is for hard-disks to increase lifetime, or prabably a few more TRIMed blocks on SSD, but you still should not exceed a time in which your cache normaly becomes full, because, like said above, a full-cache with lots of defered-writes that still need to be flush is bottlenecked to disk-write-speed.

So no-write-flush on shutdown is nothing more than a safety option to make long timeouts not kill your filesystem entirely and a safety option for those who save their importantant documents <10 seconds (standard) before they want to reboot or shutdown.

BTW: you only experience long shutdown-times when using long defer-write timeout. That would make it neccessary to write (in this example) up to 4GiB defered-writes just in the moment you like to shutdown. With the default 10 sec timeout, there would not be any significant amount of data be left and your shutdown pretty much is the same speed than without defer-write.

Not to be open for good arguments: Why you love it at all so much?

It's been removed for a good reason and in old version it clearly states, that you should exactly know what you are doing. One reason is people claiming romex make their data get lost.. what is not true. Newbs should not tickle options they have no clue about and this option can lead to fatal data-loss. Re-inventing such feature would result in lots of support-request and unsatisfied constumers.

Hope i could clear all questions.

P.S.: Im sry i explained so much things about defer-writes, and I hope that im right with my conclusions, but i think these "extrem long defer-write timeouts", which some users really recommend, is the root of what is making you want this problematic/useless option back.
Post Reply