A job mounts its input tree read-only and its output volume writable — what does the read-only mount actually prevent?
answer
- a mode on one path
- this container's view, not the storage
- refused at the attempt, not later
- other writers are unaffected
- no copy is taken at start-up
basics
~20 sOnly this container's writes through that one path. The write is refused at the moment it is attempted. It does not freeze the underlying storage, does not stop other writers, and does not cover any other path the container can reach.
solid answer
~50 sA read-only mount is a property of **this mount**, not of the storage behind it. Writes the job attempts under that path are refused outright, whatever the file's ownership bits say, and refused at the attempt rather than dropped silently later. What it does not do: it does not make the source immutable — a process outside, or another container mounting the same source writably, can still change it, and the job sees those changes as they happen — and it does not touch anything else the container can write, including its output volume and any scratch space. Its real value is blast radius: a bug in the batch cannot corrupt or half-consume a drop directory that an upstream producer owns, and habits like renaming inputs to mark them processed fail loudly on the first run instead of quietly mutating shared state.
go deeper
The useful fact is the scope: read-only describes one mount in one container. The job cannot write through that path, and everything else it can reach is unchanged.
Explain the two halves — the write is refused at the attempt, and the storage behind the mount is not frozen — and why that means the input set can still change mid-run.
Show what you do with it in practice: which trees you declare a reader of, where progress and temporary files go instead, and how a producer hands over a complete file so a live view never exposes a half-written one.
The angle is ownership of shared data. Making the mode explicit turns an unwritten convention about who may write a shared tree into something reviewable in a spec, which is what makes it hold as the number of consumers grows.
## What the declaration covers A mount is declared with a mode, and **read-only** narrows it to reads for that path, in that container, for that container's life. It is worth being precise about all three qualifiers, because each one is a place people over-read the guarantee: - **That path.** The mode applies to the mount point and everything under it. The rest of the container's filesystem is unaffected, including the output volume and any scratch area. - **That container.** The mode is a property of this mount, not of the storage. The same source can be mounted writable somewhere else at the same time. - **That life.** It is a declaration in the spec, not a change to the data. Take the mount away and the storage is exactly as writable as it ever was. A write attempt through a read-only mount is **refused at the attempt**. The call fails; nothing is buffered, deferred or silently discarded. That matters for diagnosis: the job fails at the line that tried to write, not later and not somewhere else. ## What it prevents and what it does not | Attempt | Result under a read-only input mount | |---|---| | The job writes a file under the mount point | refused — the write call fails immediately | | The job writes to its output volume | unaffected; that mount has its own mode | | The job writes to scratch space elsewhere in its filesystem | unaffected | | Another container mounts the same source writably and writes | unaffected; the mode is per-mount | | A process outside the container writes into the same storage | unaffected | | The source's contents change while the job runs | visible immediately; no snapshot was taken | ## Why it is not a snapshot The most common over-reading is that a read-only input tree gives the batch a stable view of its inputs. It does not. The mount is a **live view** of storage that other things are still writing to. Over a long run, files can appear, change size, or disappear between the moment the job listed the directory and the moment it opened each file. If the batch needs a stable input set, it has to create that stability itself: - read a manifest of the names and content identities it intends to process, then process exactly that set; - or copy the set it will process into storage it controls, and work from the copy; - or agree a hand-off convention with the producer, such as writing to a staging name and moving into place only when complete, so a partially written file is never visible under a name the job will pick up. ## What turning it on tends to break Read-only mounts are usually added to an existing job, and they surface habits that were quietly mutating somebody else's data: 1. **Marking inputs as processed** by renaming them or writing a marker file beside them. This is the most common one, and it is exactly the behaviour the mount is there to stop. 2. **Lock files** placed in the input directory to coordinate between instances. 3. **Temporary files** written next to their source rather than into a scratch area, usually because that was the shortest path when the code was written. 4. **Tools that open for read-write by default** even when they only read, which fail at open rather than at write and so look like an unrelated error. Each of these needs somewhere else to go, and the somewhere else is storage the workload owns: the output volume, a declared scratch area, or a record in a datastore keyed by the input's name and content. Progress belongs to the consumer, not to the producer's tree. ## Why bother The input tree in this scenario is shared: an upstream producer drops files into it and this batch consumes them. The mode is the only thing in the spec that says which of the two owns it. Without it, a single bad path join in the consumer can delete or overwrite the producer's files, and the failure surfaces in the producer's next run rather than in the run that caused it. With it, the consumer's bug fails immediately, in the consumer, with a message that names the path — and the shared tree is unchanged. Read it as a declaration of intent with teeth: *this job is a reader of this tree*. It is cheap, it is checkable in the spec, and it costs nothing at runtime. What it is not is a guarantee about the data itself, and a candidate who claims the stronger version has misread which side of the mount the mode applies to.
- The job needs to mark each input file as processed — how, if the input tree is read-only?Track progress in storage the job owns: a record in the output volume or a datastore, keyed by the input's name and content identity. Renaming inputs or dropping a marker file beside them is precisely the habit the read-only mount exists to block, because it mutates a tree the producer owns.
- What does the job see if the source directory changes while it is running?The current contents. A read-only mount is a live view, not a copy taken at start-up, so files can appear, change or vanish mid-run. A batch that needs a stable input set must read a manifest first, or copy the set it intends to process into storage it controls.
saying these in an interview costs you the question
- Thinks a read-only mount makes the underlying storage immutable for everyone.
- Expects a read-only mount to give the job a consistent snapshot of its inputs.
- Believes the mode covers the whole container filesystem rather than one path.
- Assumes writes through a read-only mount are dropped silently instead of refused.
- Says a rename of an input file is allowed because renaming is not writing.