Client directory structure

Review: the client directory structure looks like

projects/
    einsteinathome.org/
        file_physical_name
        ...
slots/
    0/
        file_logical_name
        ...
    ...

Each job runs in its own slot directory. The files in the slot directory are (by default) "link files" that point to files in the project directory (sort of like symbolic links).

This has the advantage that if there's a big input file, we don't need to copy it into the slot directory. And if there are multiple concurrent jobs that use the file, they share a single copy of it.

VBox apps (current)

If a VBox app has input and/or output files, they're passed into and out of the VM via a directory named "shared" that (on the host) is in the slot directory, and (in the VM) is mounted typically at root/shared.

Input files are copied (by Vboxwrapper) from the project directory into the shared directory before the job starts. When the job is done, the client moves the output files from the shared directory to the project directory.

VBox apps (proposed)

The above design is inefficient in terms of both time (copying) and space (duplicate files). I propose that vbox_job.xml file have two new options:

<share_slot_dir/>

If set, Vboxwrapper shares the slot directory with the VM. For compatibility, still call it shared in the VM. If this is set, the following are not allowed:

<enable_shared_directory/>
<copy_to_shared/>
<copy_cmdline_to_shared/>

The second option is

<share_project_dir/>

If set, Vboxwrapper shares the project directory with the VM, with the name project.

The script vboxwrapper/boinc_resolve can be used (in the VM) to converts a link file (in /root/shared) to the path of the corresponding physical file (in /root/project).

For example, if the VM runs a program prog that takes an input file and produces an output file, with logical names in and out, the top-level script might look like

#! /bin/sh
cd /root/shared
inpath=`boinc_resolve in`
outpath=`boinc_resolve out`
prog $inpath $outpath

Home