That sounds as if you haven't fully considered the write-caching abilities, and multi-threaded nature, of modern operating systems - that Eric was trying to alert you to.
There are, admittedly, two cases to be considered: 1) Client crash, leaving cached data available to be handled by the operating system. 2) Sudden loss of power, resulting in only data already committed to non-volatile storage being available on restart. I'll leave it to the engineers to devise a solution that covers both cases. >________________________________ > From: David Anderson <[email protected]> >To: Eric J Korpela <[email protected]> >Cc: BOINC Dev Mailing List <[email protected]>; Rom Walton ><[email protected]> >Sent: Thursday, 27 February 2014, 23:40 >Subject: Re: [boinc_dev] Lack of documentation on the Android clients. > > >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. > > > _______________________________________________ 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.
