The client is the only process that uses client_state.xml. The reason for writing changes to disk is the need to recover from client crashes or unexpected exit - e.g., so the client doesn't restart a job that's already finished.
In the current design, a lot of data (as much as 1MB) is written even when only a few bytes have changed. This could be reduced in various ways, e.g. by having per-project state files. We can consider this, though I'm not sure the cost/benefit merits it right now. -- David On 27-Feb-2014 2:04 PM, Eric J Korpela wrote:
I've been thinking a lot about the problem of reduced lifetime of flash based devices due to write cycles from BOINC and BOINC apps. Memory mapped files for memory allocations seemed a potential solution to SETI@home's memory problem. I've abandoned it, because it would lead to SSD degradation on the low memory devices. Is client_state.xml only read and written by the core client as the means of tracking state? Or do other processes read or write it? The best solution I've come up with for small files that change frequently is to mmap() them with MAP_SHARED. Then fork a process that sits in a sleep loop, and checks to see if the parent died. If it did, them msync() the file. It also needs signal handling that msync()s on any signal that can be handled. The parent can also msync() on exit. Since standard file operations in linux are performed though the virtual memory subsystem, other processes can see the writes before they are written to disk. On Thu, Feb 27, 2014 at 11:26 AM, David Anderson <[email protected] <mailto:[email protected]>> wrote: AFAIK the client writes client_state.xml only when something important changes, like jobs finishing, new jobs arriving, file transfers finishing, etc. It's possible that the number of writes could be slightly reduced. I don't think a huge reduction is possible. The log flag <statefile_debug> shows when and why the state file is written. -- David On 27-Feb-2014 8:59 AM, Raistmer the Sorcerer wrote: and how quickly it will wear out their expensive hardware and data bundle. This last line led to some question - does BOINC (not only BOINC for Android, BOINC for Windows too) have option to change time interval that it uses to write client_state.xml file? Looks like this constant status update wear storage the most. For separate science apps user has checkpoint interval option that he can increase if he quite confident in own computing system. But what about BOINC itself? Maybe worth to update client_state.xml only by checkpoint intervals? Or to provide separate adjustable option for this interval? It's nothing to do with original lack of documentation topic, but worth to think about too IMHO. _________________________________________________ boinc_dev mailing list [email protected] <mailto:[email protected]> http://lists.ssl.berkeley.edu/__mailman/listinfo/boinc_dev <http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev> To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
_______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
