Your batch job's data directory is a host path mounted into the container — how does that differ from a platform-provisioned volume?

## What a mount is at all Every path a containerised process sees comes from somewhere. Most of them come from the **image**: read-only layers stacked into a single filesystem view. On top of that sits a thin writable area belonging to this one instance, which is discarded when the instance is replaced. A **mount** is an override for one path: it declares that this directory inside the container is not image content — it comes from outside the container, and writes through it go outside too. So the real question is what *outside* means. There are two answers, and they behave nothing alike once a scheduler is involved. ## A host path A **host path mount** (also called a **bind mount**) names a directory on the machine the container happens to be running on and makes it appear at a chosen path inside the container. Nothing is provisioned and nothing is recorded anywhere: at start-up the platform resolves that path on that machine, and from then on the process reads and writes the host's filesystem directly, through the boundary. The properties you should be able to state on demand: - **The storage belongs to the machine, not to the workload.** It existed before the container and remains after it — on *that* machine. - **Ownership and permission bits pass through unchanged.** Whatever numeric owner and mode the host filesystem records is what the process inside must satisfy in order to write. - **The path is the entire contract.** Whether the directory holds the data you meant is not something the platform can check for you. - **If the directory is missing, platforms differ.** Some refuse to start the container; some create an empty directory at that path. Neither outcome is the one you wanted. - **The platform does not know this is state.** It will not size it, snapshot it, list it in an inventory, move it, or stop a second workload writing the same files. ## A managed volume A **volume** is storage the platform provisions and tracks as an object of its own, with a lifecycle separate from any container. The workload spec names a volume and the path to mount it at; making it exist, attaching it to whichever machine the workload is placed on, and keeping it after the container is gone are all the platform's responsibility. - The volume belongs to the **workload**, so a replacement container finds the same bytes. - Because the platform knows the volume exists, it can re-attach it after a restart, decline a placement where it cannot attach it, and offer capacity, expansion and snapshot operations on it. - The spec is portable, because it **asks for storage** rather than pointing at somebody's directory. The same spec run in another environment gets storage there too. (How a workload asks for a particular size and writer count is a subject of its own.) - Many platforms can set the ownership of a volume's contents at attach time, which is one practical reason a volume is the easier answer for a process that does not run as root. ## Side by side | | Host path mount | Platform-provisioned volume | |---|---|---| | What you name | a directory on whichever machine runs the container | a volume the platform creates and tracks | | Belongs to | the machine | the workload | | If it does not exist | platforms differ: refuse to start, or create it empty | the platform provisions it | | After replacement on another machine | the data stays behind; the container sees the new machine's copy of the path | the same volume is attached where the workload lands | | Ownership of contents | whatever the host filesystem already records | the platform can set it at attach time | | Visible to capacity, snapshot and backup tooling | no | yes | ## Why it keeps working on a laptop On a development machine the two look identical, because every assumption a host path makes happens to be true: one machine, a directory you created yourself, a process running as an id that can write it, and nothing moving the workload anywhere. Run the same spec against a node you did not choose and each assumption becomes a question, and the failures are quiet: 1. The workload is replaced on another machine, and the new container finds whatever *that* machine has at the path — usually nothing, occasionally another workload's leftovers. 2. Two copies of the workload land on two machines, each with its own version of "the" directory, so behaviour now depends on placement. 3. The directory exists but is owned by an id the process is not, and the first write is refused. 4. Nothing backs it up, because nothing in the platform knows it is data. ## When a host path is still right It is right when you genuinely mean **this machine**. An agent that has to read its own host's files, node-local scratch or cache you are content to lose, and the developer loop where you edit a tree on your laptop and want the change live inside the container without rebuilding an image are all cases where the data is a property of the machine — which is exactly what a host path expresses. Everything else, and specifically anything a replacement container must still find, wants a volume the platform provisions, tracks and re-attaches.