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]>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] > 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.
