Treat Colab Runtimes as Disposable: A Drive-Mounted Workspace Pattern

The problem: your work disappears

You install a package, download a dataset, train for two hours, and close the tab. When you return, the runtime has been reassigned. The package is gone, the dataset is gone, and the checkpoint you wrote to /content never existed. Colab virtual machines are disposable. Anything that lives only on the local filesystem is temporary.

The thesis: make Drive the source of truth

Instead of fighting the ephemeral runtime, accept it. Use the Colab Drive integration to mount Google Drive into the session. Treat that mount point as your durable workspace. Keep code, datasets, checkpoints, and logs there. The notebook becomes a thin control layer that reads from and writes to a stable path.

One setup cell, stable paths

Put a single cell near the top of the notebook that mounts Drive, defines a project root, and creates standard subdirectories. Every later cell references paths relative to that root. This makes the notebook restartable and portable across sessions.

# Run this cell first in every session.
from google.colab import drive
from pathlib import Path

# Mount Drive; this triggers an interactive OAuth prompt.
drive.mount('/content/drive')

# Define the durable project root.
PROJECT_ROOT = Path('/content/drive/MyDrive/colab-projects/my-experiment')
DATA_DIR = PROJECT_ROOT / 'data'
CHECKPOINT_DIR = PROJECT_ROOT / 'checkpoints'
LOG_DIR = PROJECT_ROOT / 'logs'

# Create standard subdirectories if they do not exist.
for d in (DATA_DIR, CHECKPOINT_DIR, LOG_DIR):
    d.mkdir(parents=True, exist_ok=True)

print(f"Project root: {PROJECT_ROOT}")
print(f"Data dir: {DATA_DIR}")

Run this in the notebook runtime. It requires the standard Colab Drive integration permissions. The mount prompt asks for Google account authorization; the session then sees Drive under /content/drive.

Worked example: dataset and checkpoints in Drive

Suppose you are training a model on a public dataset. Download and extract it once into the Drive-backed data directory. In later sessions, point your data loader at the same path and write checkpoints and logs into their own subdirectories.

# Only run this once; skip if the archive already exists.
import urllib.request
import tarfile

archive_path = DATA_DIR / 'dataset.tar.gz'
extract_path = DATA_DIR / 'dataset'

if not extract_path.exists():
    if not archive_path.exists():
        urllib.request.urlretrieve(
            'https://example.com/dataset.tar.gz',
            archive_path
        )
    with tarfile.open(archive_path) as tar:
        tar.extractall(path=DATA_DIR)

# Later sessions: load from the durable path.
# train_loader = DataLoader(DatasetFolder(extract_path), ...)

# Write checkpoints and logs under the project root.
# torch.save(model.state_dict(), CHECKPOINT_DIR / 'epoch_10.pt')

The key decision is that extract_path and CHECKPOINT_DIR never change. A disconnected browser does not matter because the next session sees the same files.

The trade-off: Drive I/O shape

Drive is convenient for durable artifacts, but it is not a high-performance filesystem. Workloads that read or write many small files can crawl. If your training loop pulls thousands of individual images or writes per-step tensorboard files directly to Drive, you may spend more time on I/O than compute.

For those cases, keep the hot data on the runtime's local disk and copy snapshots back to Drive periodically. Use Drive for the durable checkpoint and the final artifacts, not for every intermediate read.

Workload	Recommended location	Sync pattern
Model checkpoints, final features	Drive	Write directly
Many small training files	Local disk	Copy to Drive at epoch boundaries
Logs and metrics	Drive	Append or write JSONL

Concurrency and quotas

A mounted Drive is shared mutable state. If you open two runtimes and both write to checkpoints/model.pt, one will overwrite the other. Use run-specific subdirectories or atomic write-then-rename patterns.

Also remember that Drive storage counts against your Google account quota. A 50 GB dataset in Drive is 50 GB you cannot use for other Google services. Plan cleanup deliberately.

How to verify the pattern works

Do not assume persistence. Test it.

1. Run the setup cell, then write a small marker file: (PROJECT_ROOT / 'marker.txt').write_text('hello').
2. Restart the runtime from the Colab menu or trigger a factory reset.
3. Remount Drive and confirm the marker file still exists.
4. Benchmark reading 1,000 small files from Drive versus local disk to see if your workload needs local caching.

Actionable closing

Treat the Colab VM as a cattle, not a pet. Your notebook should be a reproducible script that assumes nothing survives a restart except what you explicitly saved to Drive. Add the setup cell today, move your dataset paths under the project root, and separate long-running scripts from the interactive notebook so a disconnected tab does not kill your computation. Check current Colab usage limits and Drive quotas in your own runtime before committing to large persistent datasets.