Skip to content
This repository was archived by the owner on Sep 3, 2022. It is now read-only.
This repository was archived by the owner on Sep 3, 2022. It is now read-only.

Add more sophisticated volume mappings for Datalab instances #1283

@ojarjur

Description

@ojarjur

This issue splits off the feature requests from #1280 regarding volume mappings for /tmp and /data.

For /tmp, we already have a volume mapping that maps that directory to /mnt/disks/datalab-pd/tmp in the host VM, but we never clean that out.

We should change our startup script to wipe out the contents of the host directory on startup. That would make the /tmp directory inside the container match the expected semantics of /tmp (that it is wiped out when the machine restarts).

The volume mapping for /data is a completely new thing. Currently, the only volume mapping we have for persisting user data requires placing it under the /contents/datalab directory (soon to change to just /content).

That allows users to save data such that it survives container restarts, but the /content directory is also automatically backed up to GCS.

That makes the existing mapping good for saving notebooks, but potentially too expensive for data that can be recreated if necessary.

The idea behind a /data directory is to fill the gap between /tmp and /content. It would hold data that the user doesn't want to be automatically discarded, but that also does not need to be persisted in their backups to GCS.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions