A second transcoding worker cannot attach the block volume the first still holds — what is the limit, and how do you get around it?

## What "attached" actually means A block volume is a device. It offers one operation in each direction: read the block at this offset, write the block at this offset. It has no notion of a file, a directory, free space or a lock. All of that is created by the **filesystem**, which is code running in the kernel of the machine the volume is attached to, and which keeps a great deal of state in that machine's memory: - **A cache of metadata** — where files live, how large they are, which blocks belong to which file — read once and reused. - **A free-space map** of which blocks are available to allocate. - **A journal** of changes it intends to make, so a crash can be recovered into a consistent state. - **Dirty page cache**: writes the application has issued that have not reached the device yet. None of that is on the volume at the moment it matters; it is in one machine's RAM. ## Why two machines cannot simply both mount it Give the same volume to two machines read-write and both run that code independently. Machine A allocates blocks its free-space map says are free; machine B's map, read minutes ago, says the same blocks are free and hands them to a different file. Machine A extends a directory; machine B is still working from a cached copy that does not contain the entry. Each journal replays changes the other never saw. The result is not a race with a winner — it is a filesystem eaten from the inside, and it is usually discovered long after the writes, when a read returns another file's bytes. So the platform enforces a single attachment. It is not an arbitrary quota; it is the only honest contract a device with no file semantics can offer. Some providers do offer a multi-attach mode, and it is worth knowing what it is and is not. It lets several machines see the same device — and it is only safe with a **filesystem designed to coordinate**, where the machines talk to each other to agree on allocation and locking. Attaching an ordinary single-machine filesystem in that mode corrupts it exactly as described above. Multi-attach removes the platform's guard rail; it does not remove the problem. ## The ways out, and what each costs | approach | who arbitrates | good for | the cost | |---|---|---|---| | object store for the shared artefact | nobody — keys are independent | publishing finished renders many readers fetch | no in-place edits; each worker needs its own scratch | | shared mount | a file service the machines reach over the network | several workers writing into one tree with file semantics | a network round trip per operation; small files hurt | | detach and reattach | the platform, one holder at a time | handing work over between workers | needs a clean unmount, and fencing if the holder is stuck | | coordinating filesystem on a shared device | the filesystem's own cluster protocol | specialised workloads that need raw block sharing | real operational complexity; rarely worth it | For a transcoding fleet the first line is nearly always the right one. Each worker gets its own volume for scratch, and the finished render is published to a key. The workers never need to see each other's bytes, only each other's outputs, and outputs are exactly what a key-addressed store is for. ## The handover trap When a handover is genuinely needed, detach-and-reattach has a failure mode people discover during an incident rather than a design review. A clean detach requires the holder to unmount, flushing everything still in its page cache. If the holder is wedged — hung kernel, unreachable, paused — it cannot unmount, so you are choosing between waiting and forcing. Forcing a detach abandons whatever had not been flushed, and if the machine later wakes up still believing it owns the volume, it can write stale blocks over the new holder's work. That is the split-brain the fencing step exists to prevent: the old holder must be provably stopped, not merely assumed gone, before the new one mounts. ## The zone constraint that comes with it A block volume lives inside one **availability zone** — one failure domain — and can only be attached by a machine in that zone. So "give it to the other worker" already presumes the other worker is in the same zone, and building a failover that crosses zones means copying the data, not moving the attachment. That is a design constraint on the whole fleet, not a detail of one attach call: if your recovery plan requires another zone, the shared artefact cannot be sitting on a block volume.