A remote machine that was off-line for the entire run of a CAM25 model accumulated almost 2 GB of upload files. The model ran to completion, including generating the restart file and the "out" file. However, when the machine was put online it immediately crashed with a "Disk usage limit exceeded" error.

The client state XML file has some headroom for the individual uploads (150 MB vs ~100 MB); the restart file is 90 MB. There is plenty of free disk space (>100 GB) and the BOINC Manager settings are default, so there should be no limits from that (BM 7.6.33).

Googling throws up some reports of errors on other projects related to virus checkers. But, if that is the case, why only at the end and why for that model and not others that ran online? Or is there some other gross upload setting that needs to be bumped for this very large model?

Interesting,
I tend to only run models offline when I want to look at the file sizes etc. before they upload. I wonder if it is some obscure limit imposed by BOINC such as the limit on the clientstate.xml that caused problems before 7.6.33?

This one's out in the country with dodgy broadband. I was indeed running it offline to check the file sizes, but when contact is lost to that machine then both remote access clients I use can't get back in until a human being intervenes (in this case me on Boxing Day) - so it sat there crunching until the end. Usually a crash causes the files to be deleted but the files were still there: it was only when network access was enabled that the crash occurred and the files were deleted - almost a day after the model had actually finished.

This is a result of a setting in client_state.xml. On the dev site for d801, Ian said the following when I got a disk limit error:

@george16 @sihanli1 The disk limit causing that is the one set in the workunit's <rsc_disk_bound> setting. For all of my WAH2 tasks on the beta and main projects it's set to

<rsc_disk_bound>2000000000.000000</rsc_disk_bound>

This size limit is exceeded if too many upload files get queued up for the cam25 model. Obviously they didn't up this bound when the problem was reported.

Thanks, George. E-mail reminder duly sent, though hopefully that setting should not affect too many people.

The rsc_disk_bound has now been increased, so this shouldn't happen again for that model.

The rsc_disk_bound has now been increased, so this shouldn't happen again for that model.

But just to be clear, any currently running cam25 models that have a large queue of uploads could still have the problem. I would think that would be very few instances though. Any future cam25 batches should not have this issue.