how do i determine the optimal defer write time for a cdrive and a seperate ssd that houses my documents?
i currently have it at the default 10 seconds. Is that optimal?
defer write for how long
Re: defer write for how long
The defer write timeout determines when your drive will begin to write your stuff to the real drive.
It does not mean that cached write data will be discarded, only that it's being written to disk... what increases security/integrity of your data in case of power-loss.
Even 1 second still will sustain lifetime of your SSD longer than before. Your risk of loosing actual data in case of power-loss, is only loosing the last 1 second of anything.
Putting it on hours, days, weeks etc. is non-sense, you will likely be quickly limited to disk speed as before but putting your data at risk for that time-period, so in case of a power-loss you will loose anything you wrote to that disk in {hours,days,weeks,etc}. Please do not do that.
I recommend you in 99% of cases to keep it that low or even put it lower for high speed SSDs. 10 is good. As far as I know latest version of Primo chooses little higher for HDD.
Problem is when your defer-write data size exceeds your cache-size within the timeout...you're instantly limited to disk-speed even for read-rates in a R/W-combo, because it cannot read or write to cache, before deferred data have been written.....farewell ram-speed, so you better let the algorythm be allowed to discard cached-writes as soon as possible, so in case cache hits full, it can free space for your new actual task.
As a formula you pick your cache-size in megabyte and devide through your drives read-rates in megabytes per second. The result would be the maximal time in seconds your cache could be filled up from the drive. This is imho the perfect time when defer write should start to always keep algorythm good working.
Just idealistic example: 2048 Mb / 204,8 Mb/s = 10 seconds
It does not mean that cached write data will be discarded, only that it's being written to disk... what increases security/integrity of your data in case of power-loss.
Even 1 second still will sustain lifetime of your SSD longer than before. Your risk of loosing actual data in case of power-loss, is only loosing the last 1 second of anything.
Putting it on hours, days, weeks etc. is non-sense, you will likely be quickly limited to disk speed as before but putting your data at risk for that time-period, so in case of a power-loss you will loose anything you wrote to that disk in {hours,days,weeks,etc}. Please do not do that.
I recommend you in 99% of cases to keep it that low or even put it lower for high speed SSDs. 10 is good. As far as I know latest version of Primo chooses little higher for HDD.
Problem is when your defer-write data size exceeds your cache-size within the timeout...you're instantly limited to disk-speed even for read-rates in a R/W-combo, because it cannot read or write to cache, before deferred data have been written.....farewell ram-speed, so you better let the algorythm be allowed to discard cached-writes as soon as possible, so in case cache hits full, it can free space for your new actual task.
As a formula you pick your cache-size in megabyte and devide through your drives read-rates in megabytes per second. The result would be the maximal time in seconds your cache could be filled up from the drive. This is imho the perfect time when defer write should start to always keep algorythm good working.
Just idealistic example: 2048 Mb / 204,8 Mb/s = 10 seconds
Re: defer write for how long
First of all, don't ever enable the defer-write without having an UPS or when your system may crash e.g. when you update a device driver - in the latter case just pause the defer-write, do the thing, then resume it.
In your case 10 sec is as high as a safe choice could be considering you are working with important documents. Of course even a safer choice would've been to disable it.
In my case a 3600sec defer-write 128MB cache (plus the 4KB block adds as much of overhead) works perfectly for an SSD system drive by caching all that small stuff that is constantly written to system journals, application logs, temp folder etc - PrimoCache statistics show a 50% reduction of megabytes actually written due to the fact that those files are updated/rewritten/deleted many times per hour so in 50% cases there's no need for them to exist outside the cache.
In your case 10 sec is as high as a safe choice could be considering you are working with important documents. Of course even a safer choice would've been to disable it.
In my case a 3600sec defer-write 128MB cache (plus the 4KB block adds as much of overhead) works perfectly for an SSD system drive by caching all that small stuff that is constantly written to system journals, application logs, temp folder etc - PrimoCache statistics show a 50% reduction of megabytes actually written due to the fact that those files are updated/rewritten/deleted many times per hour so in 50% cases there's no need for them to exist outside the cache.
Re: defer write for how long
In certain areas in the world there's statisically high likely no considerable practical use for an UPS, because power-outage not happened over decades 
...ya still in the next moment it may happen ^^
The measures to ensure safety, availability and integrety of data strongly depends on its "critical" meaning to you.
You probably do not care at all if your most critical "personal-computing" task is editing some data like documents, pictures or home-videos... and if you consider these critical i assume you keep a simple backup of them.
Considering any "critical" task, one probably not put it into volatile RAM-DIsk or put it elsewhere then the volatile RAM-cached disk with defer-write-(timeouts).
Even with UPS and redundant PSU nothing of these protects your system from an outage due to memory-subsystem failure...so you probably need to buy ECC..... and still than other bluescreen related software/hardware-errors resulting of bad programming or manipulation (exploiting overflows) or defect devices still can happen and wipe all your critical stuff.
The advantage of longer defer-write on the other hand is that you have that blocks available for read during that time-period. Lets say you download 4Gib Game from Steam in about ~12 minutes... with a timeout of 864 seconds (every 14,4 minutes or 100 times a day) this data if requires installation is installed within a brief moment and can be startet instantly. Primo than stll advices the data to be written to disk in the background, while your game "read-access" the blocks directly from RAM!
...ya still in the next moment it may happen ^^The measures to ensure safety, availability and integrety of data strongly depends on its "critical" meaning to you.
You probably do not care at all if your most critical "personal-computing" task is editing some data like documents, pictures or home-videos... and if you consider these critical i assume you keep a simple backup of them.
Considering any "critical" task, one probably not put it into volatile RAM-DIsk or put it elsewhere then the volatile RAM-cached disk with defer-write-(timeouts).
Even with UPS and redundant PSU nothing of these protects your system from an outage due to memory-subsystem failure...so you probably need to buy ECC..... and still than other bluescreen related software/hardware-errors resulting of bad programming or manipulation (exploiting overflows) or defect devices still can happen and wipe all your critical stuff.
The advantage of longer defer-write on the other hand is that you have that blocks available for read during that time-period. Lets say you download 4Gib Game from Steam in about ~12 minutes... with a timeout of 864 seconds (every 14,4 minutes or 100 times a day) this data if requires installation is installed within a brief moment and can be startet instantly. Primo than stll advices the data to be written to disk in the background, while your game "read-access" the blocks directly from RAM!