Writable FUSE mount » History » Version 1
Peter Amstutz, 07/23/2014 09:28 AM
| 1 | 1 | Peter Amstutz | h1. Writable FUSE mount |
|---|---|---|---|
| 2 | |||
| 3 | h2. Problem |
||
| 4 | |||
| 5 | When running a job in order to write output to Keep it is necessary to either a) use the Keep API in the Python SDK or b) write to a staging directory and then use arv-put to upload the contents. Both of these have disadvantages; using the Python API directly is only practical if the user script itself is written in Python and can easily accommodate writing its output to Keep (unfortunately arvados.StreamFileReader does not conform to the Python File object interface and cannot be used as a drop-in replacement.) Writing to a staging directory requires sufficient scratch space on the compute node, and cannot stream the output to Keep servers as it is being written, instead requiring a potentially time consuming upload step after the actual job is finished. |
||
| 6 | |||
| 7 | h2. Goals |
||
| 8 | |||
| 9 | * Accommodate the vast majority of scripts and tools that naturally write their output as regular files |
||
| 10 | * Improve performance by asynchronously streaming blocks to Keep as they are written, instead of waiting until the job is finished |
||
| 11 | |||
| 12 | h2. Proposal |
||
| 13 | |||
| 14 | We already support a read-only fuse mount; this has proven to be a key piece of infrastructure that greatly simplifies |