Atomic pathname replacement visibility across mount namespaces for zero-downtime redeploy

To achieve zero-downtime redeploy using Linux-native primitives, you must distinguish between filesystem-level atomicity (rename) and mount-level visibility (move_mount). The visibility of a swap in a peer mount namespace depends entirely on the propagation flags of the underlying mount point.

Atomicity vs. Visibility

The rename(2) system call is atomic within a single filesystem. When you rename a directory or file, any new open(2) calls hitting that path will immediately resolve to the new inode. Existing file descriptors held by the application remain valid and continue to reference the old inode until they are closed. This is the foundation of zero-downtime swaps.

However, atomicity does not extend across bind mounts. If a peer namespace has a bind mount at /app, and you rename the source directory on the host, the existing bind mount in the peer namespace will still point to the old (now moved) directory. To update the peer namespace, the bind mount itself must be refreshed or the path must be handled differently.

move_mount and Namespace Propagation

move_mount(2) allows moving a mount point within the tree. Its visibility across namespaces is governed by propagation flags:

• Shared: If the source mount is marked shared, a move_mount in one namespace will propagate to all peer namespaces sharing that mount tree.
• Slave: Changes propagate from the master to the slave, but moves in the slave do not propagate back to the master.
• Private: Changes are local to the namespace and will never be visible to peers.

While a user namespace with CAP_SYS_ADMIN can perform move_mount within its own context, it cannot force that change onto the host or peer namespace unless the host-level mount was already configured with shared propagation before the namespace joined.

Implementation Steps for Zero-Downtime Swap

To reliably swap an application without an external orchestrator, follow this pattern:

1. Prepare the new application version in a sibling directory (e.g., /opt/v2).
2. Use rename(2) to atomically swap /opt/current with /opt/v2.
3. If using bind mounts in namespaces, ensure the parent mount is shared. If not, you must re-execute the bind mount command within the peer namespace to point to the new inode path.
4. The application process should continue accepting new connections (which will hit the new path) while the old process finishes in-flight requests and exits gracefully.

Verification Commands

To verify your environment supports these operations, use the following checks:

# Check propagation flags of the application mount point
find /proc/mount -o propagation | grep "/your/path"

# Verify inode persistence after a rename
lsof -p [PID] | grep /your/app

Assumption: This analysis assumes a Linux kernel 4.19 or later (where move_mount was introduced) and that the underlying filesystem supports atomic rename (e.g., ext4, btrfs).