If you are on Windows, use PrimoCache (use the write-cache only):
https://www.romexsoftware.com/en-us/primo-cache/index.html

If you are on Linux, use their built-in write cache:
https://lonesysadmin.net/2013/12/22/better-li...rformance-vm-dirty_ratio/

I have not bothered to looks at the writes here, since they aren't sending out many, but I would think that a cache size of 2 GB and a latency (write-delay) of 30 minutes should work. I use them on all of my machines to protect the SSDs.

Yes. I don't know of any free ones. Primo spent years developing it to eliminate all the errors. I have never seen such a long beta.

You could try a ramdisk instead, but you have to size them to hold the entire BOINC data folder. I think there are some free ones, but I use Primo Ramdisk (the best monitoring tools) or Dataram.

That reminds me of the good old days, when I had a large RAMdisk for the CEP2 project here on WCG. It had a horrendously high write rate, over 1 TB/day for 8 cores. Also, CPDN had a high write rate back then, though less now.

The limitations on the write rate for mechanical disks caused errors too. I was able to eliminate them with the ramdisk. With enough memory, you can do a lot of things.

The kitties' kibble bowl is bare here as well. Nothing coming through today.

Meowsigh

EDIT..........
I guess all it took was for the kitties to meow louder...........LOL.
After 7-1/2 hours of nothing, I posted this and got 16 fresh bits of kibble half an hour later.

Meow!

A quick note about workunit availability for the project. As noted in the post about the outcome of the stress test the researchers have a limit on how fast they can process results and make use of them. We are currently working with them to target about 500 batches per day (this is combined between CPU and GPU). It is a little tricky to manage to this because even though there is a consistent number of ligands per batch, the number of workunits created per batch varies based on the estimated difficulty of the ligands. Thus we have to tweak the rate we send out workunits.

Right now the 7 day average of batches for GPU is 727 batches/day and CPU is 185 batches/day. This is above the 500 batches/day goal. As a result, we reduced the GPU pace 2 days ago from 3000 workunits/day to 1700 workunits/day. We have been attempting to reduce the pace of the CPU work as well. Unfortunately, there is a fairly large set of users who only have OpenPandemics selected and thus we are not able to shift as much of the CPU power to our other projects as I had hoped. We will continue to adjust things where we can to support the 500/batches per day goal and to shift work to GPU as much as possible without making the CPU work intermittent.

I would ask that if you are someone who has only OpenPandemics selected, please consider adding Mapping Cancer Markers and/or the African Rainfall Project in addition to OpenPandemics. OpenPandemics will continue at the same pace regardless of how much CPU power is allocated to it as the GPU side will pick up any slack left over from the CPU side.