O2AS20-500T ... questions and problems

You'll have to wait for Bernd to answer that, probably.  I have no idea.

I'm responding because of these two bits:-

and

I have seen this sort of thing happen, fairly infrequently, but over many years, so the total number of times does add up.  When all tasks depending on a certain file get trashed like this, BOINC will quite often go into a long project backoff (15-20 hours or more) with a timer counting down.  This effectively leaves all the failed tasks just sitting there waiting for the backoff to end.  When I notice this sort of event, I've always been able to retrieve the failed tasks by using the 'resend lost tasks' BOINC feature that Einstein has enabled.  Essentially all I do is delete all the computation error <result> entries in the state file and, when ready to restart, force the client to update with the scheduler and thereby receive fresh copies of all those tasks.

Each time I have done this, I have found that the supposedly corrupt file is not actually corrupt at all.  I have two theories (and that's all they are) about the causes of this.  In two cases that I know of, one cause seems likely to be a RAM error.  I usually run memtest when these failures occur and a couple of errors were found in those two cases.  Replacing the faulty RAM module caused the problem to go away.

However, in other cases, no RAM errors were found.  A fairly common factor in this second larger group, is that the problem occurred right near the completion of a task.  My theory (and I could be quite wrong) is that somewhere around the start of a new task, BOINC performs some sort of MD5 check of the files that will be needed for the next task to start.  For some reason, this check can give a bogus result and so the whole cache of work depending on that bogus result gets trashed.  It appears that if the machine is under stress (heat stress springs to mind because these events seem to occur at times of heatwaves) the checksum can be miscalculated.  This is all I can come up with since, when I run an independent check of the file, it is never found to be corrupt.  I probably shouldn't say 'never' because I used to just replace the files (without testing) with known good copies.  Then I started testing and found no errors.  For the last couple of years, I've just fixed the state file and put the machine back to work without even testing.  In no case that I can think of has crunching failed to restart because a file really was corrupt.

That's what drove me to start investigating all those years ago.  My very first theory was a bad block suddenly appearing with a data file spanning it.  I tried renaming the file to file.bad and installing a fresh copy.  The problem kept coming back, maybe days later, and with a different data file.  In the end, after running disk checks and not finding bad blocks, I had to come up with different theories.  I really remember that initial case quite clearly because the tasks would get trashed every few days or so - until I worked out it was a RAM problem :-).