Changes between Version 4 and Version 5 of BoincFiles


Ignore:
Timestamp:
May 28, 2007, 8:19:18 AM (18 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • BoincFiles

    v4 v5  
    55The BOINC storage model is based on '''files'''. Examples of files:
    66
    7     * The inputs and/or outputs of computation;
     7    * The inputs and outputs of computation;
    88    * Components of application: executables, libraries, etc.
    9     * Data for its own sake, e.g. to implement a distributed storage system.
     9    * Data for its own sake, e.g. as part of a distributed storage system.
    1010
    1111The BOINC core client transfers files to and from project-operated '''data servers''' using HTTP.
    1212
    13 Once a file is created (on a data server or a participant host) it is '''immutable'''. This means that all replicas of that file are assumed (and required) to be identical. If a file is changed, even by a single byte, it becomes a new file, and must be given a different name than the original.
     13Files are '''immutable'''. This means that all replicas of that file are assumed (and required) to be identical. If a file is changed, even by a single byte, it becomes a new file, and must be given a different name than the original.
    1414
    1515== File properties ==
    … …  
    1717Files have various properties, including:
    1818
    19     * '''Name:''' unique identifier for the file. Must be nonempty, at most 255 chars, and may not contain '..' or '%'.
     19    * '''Physical name:''' unique identifier for the file. Must be nonempty, at most 255 chars, and may not contain '..' or '%'.
    2020    * '''Sticky:''' don't delete file on client (see below).
    2121    * '''Report on RPC:''' include a description of this file in scheduler requests.
    … …  
    2626== File references ==
    2727
    28 In addition to the properties of a file itself, there are several properties of the way a particular application uses a file; this is called a '''file reference'''.
     28The way a particular application uses a file is called a '''file reference'''.
     29File references have the following properties:
    2930
    30     * '''open_name''' (or 'logical name'): the name by which the program will refer to the file (BOINC provides a mechanism for mapping logical names to physical names, so that your applications don't have to know the physical names of their input and output files).
     31    * '''logical name''': the name by which the program will refer to the file.  BOINC provides a mechanism for mapping logical names to physical names, so that applications don't have to know the physical names of their input and output files.
    3132    * '''copy file:''' use this if your application doesn't use BOINC's filename-mapping mechanism.
    3233    * '''optional:''' Use this for output files, to indicate that the application doesn't always generate the file, and that its absence should not be treated as an error.
    … …  
    4041    * On the client, input files are deleted when no workunit refers to them, and output files are deleted when no result refers to them. Application-version files are deleted when they are referenced only from superseded application versions.
    4142    * On the client, the 'sticky' flag overrides the above mechanisms and suppresses the deletion of the file. The file may deleted by an explicit [DeleteFile server request]. The file may also be deleted at any time by the core client in order to honor limits on disk-space usage.
    42     * On the server, the [FileDeleter file deleter daemon] deletes input and output files that are no longer needed. This can be suppressed using the 'no_delete' flag, or using command-line options to the file deleter.
     43    * On the server, the [FileDeleter file deleter daemon] deletes input and output files that are no longer needed. This can be suppressed setting the 'no_delete' property on the  file, or using command-line options to the file deleter.
    4344