Hello,

there’s some constant write disk access from boinc being done.

I’ve set the reference point writes to 600 seconds and there’s still writes being done every few seconds.
I’ve suspended all tasks and there’s still writes being done every few seconds.
I’ve changed, just in case the client ignores my local preferences, the preferences of each project (reference point to 600 seconds) and there’s still writes being done.

o.s.: kde neon
client: from repository : 7.16.6 x86_64-pc-linux-gnu
ram: 64 GB

help.
Thanks.

Hello,

there’s some constant write disk access from boinc being done.

I’ve set the reference point writes to 600 seconds and there’s still writes being done every few seconds.
I’ve suspended all tasks and there’s still writes being done every few seconds.
I’ve changed, just in case the client ignores my local preferences, the preferences of each project (reference point to 600 seconds) and there’s still writes being done.

o.s.: kde neon
client: from repository : 7.16.6 x86_64-pc-linux-gnu
ram: 64 GB

help.
Thanks.

OK, I am guessing here but it sounds reasonable.

Boinc is split into two parts, the client which performs the work and actions the work units and the manager that monitors and reports on progress.

You say that you’ve suspended all tasks and that should have stopped most of the client processing ( although it could still be polling for change of status and storing same) but the manager is still running and it is likely that it is logging the progress (or lack of it) that it is seeing.

As long as the amount of data written is minimal I would not worry about it, just Boinc carrying out its function.

Could be the client writing its own internal state into client_state.xml? That file isn't used in normal running, but is read at start-up - so it needs to be current in case there's a sudden power outage.

You could check the time-stamp on that file.

Thanks for answering,

the writes are done in the task folder. Granded, the writes seem small, 4k every 10 sec or less. Here's an cut/paste of iotop for one of them "../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_x86_64-pc~_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 2471115"
That was while the manager wasn't running. When it's running, doesn't seem to matter.

It is still kind of anoying and maybe "useless" that some writes are being done when there's no work done at all or task are paused.

I think we might have to endure it unless, someday, it gets fixed/changed/reviewed.

Again, thanks for answering.

What project(s) are you running?
If more than one project do all of them exhibit this?

My first thought is that it is an application writing stuff to the task folder, in which case it is the project that is responsible for the application not BOINC (which does not write the applications only provides an environment for them to run in)

There's still a boinc_task_state.xml file in every slot directory, to keep track of how far it's got. That's management data for BOINC, not for the project.

Hi,

projects are rosetta, world community grid, gpu grid, einstein, lhc.
No current tasks of lhc or einstein.
Of those running (rosetta, world community grid and gpu grid), I've only seen writes of rosetta and world community grid. The write are under the ../../projects/" not the "../../slots" folder.

I've also seen boinc writes but the "command" column on iotop just lists "boinc" as the command, no clue where it is writing.

The writes are far from excessif. But I still would have expected no writes at all if there's no job at all running or everything is paused/stopped .

Anyway thanks for your answers, I have a feeling that there's no "fix" for this.
Thanks.

There are a few things I think could be the reason.
1- If you're running Boinc from a device running off of an SD card, or very slow emmc drive, writes can be queued, and extend the time of writing.
2- The disk access that happens is not only processed WU writes. Boinc also downloads new WUs, and uploads finished WUs.
3- There also are background services that may want to access your disk from time to time.
4- If you set your writes to 600 seconds, but are processing 10 WUs, your disk will have an average WU write done to it once every minute.
So despite you setting '600 seconds' as the write interval, it will honor those 600 seconds on every WU. Maybe in the beginning all the writes happen at the same time, but as WUs finish, and new WUs start, that time interval is more spread around, and your disk will be accessed multiple times (the set time interval, divided by the amount of WUs that are being processed).

My recommendation, is to not let the writes be much longer than the default 60 seconds.
Like said, power outages.
It's also not good for a spinning HDD to enter sleep mode, and spin back up frequently. SSDs usually are ok with thousands of interactions per second, or near to non-stop access times.