Skip to main content

Attach a device to jobs and workstations

how-to · Reviewed 2026-07-31 · FEAT-0118 GA

Attach to a job​

On the job's input section, Attach from storage device → pick the device → Next.

Two modes, and the choice affects performance:

ModeWhat happensUse when
Attach without adding filesMounts the device at ~/storage_{id}/. Read and write it directlyThe dataset is large and you read parts of it
Attach and add filesCopies or symlinks specific files into the job's work/ directoryThe solver does heavy I/O on a few files

Data written to the mount persists after the job's cluster terminates, and stays available to other jobs and workstations.

Symlinked entries show a yellow chain-link icon. Copying into work/ means the solver reads local scratch rather than across the NFS mount, which is usually faster for I/O-heavy runs.

You can't attach a device and a CFS to the same job

The UI won't allow both. If you need data from an HPS and a CFS, copy it across from a workstation first.

Attach to a workstation​

Select one or more devices in Add Storage Device before launch.

Storage devices can't be attached after launch

Unlike files and jobs, a device must be specified when you create the workstation: see create a workstation.

Also: if an attached HPS terminates, the workstation dies with it, because the workstation's working directory lives on the device. See workstation files.

Once running, the device mounts in the home directory as storage_{device_id}. On Windows workstations it can be mapped to a drive letter, ask Rescale Support to enable it. That covers at most three devices, mapped to Y:, X:, and W:, and only for interactive desktop sessions, not SSH.

How many jobs can attach at once​

An HPS serves files over NFS, and that has limits people hit without warning.

Too many attached nodes will queue jobs or crash the mount

The cap is on nodes, not jobs, one 30-slot DOE counts far more than one basic job. Limits scale with coretype and core count.

On AWS, devices support a maximum of 50 slots attached at once. Exceeding a node limit queues jobs until capacity frees up. On coretypes where the limit isn't precisely defined, exceeding it degrades performance or crashes the NFS mount, and attached jobs fail to launch.

Two mitigations: run a larger HPS, or attach fewer jobs at a time. Heavy-I/O workflows hit the wall sooner than the node counts suggest.

Rescale also limits how many nodes attach simultaneously, so a single large job may start more slowly than expected.

Where the cluster launches​

Rescale attempts to launch attached job clusters in the same availability zone as the device, unless you've configured AZ preferences. Other zones are tried if that fails.

This matters for performance. A cluster in a different AZ from its storage adds latency, and on some clouds, transfer cost.