Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Union mount.
Nothing was collected or created yet.
Union mount
View on Wikipediafrom Wikipedia
In computer operating systems, union mounting is a way of combining multiple directories into one that appears to contain their combined contents.[1] Union mounting is supported in Linux, BSD and several of its successors, and Plan 9, with similar but subtly different behavior.
As an example application of union mounting, consider the need to update the information contained on a CD-ROM or DVD. While a CD-ROM is not writable, one can overlay the CD's mount point with a writable directory in a union mount. Then, updating files in the union directory will cause them to end up in the writable directory, giving the illusion that the CD-ROM's contents have been updated.[1][2]
Implementations
[edit]Plan 9
[edit]In the Plan 9 operating system from Bell Labs (mid-1980s onward), union mounting is a central concept, replacing several older Unix conventions with union directories; for example, several directories containing executables, unioned together at a single /bin directory, replace the PATH variable for command lookup in the shell.[3]
Plan 9 union semantics are greatly simplified compared to the implementations for POSIX-style operating systems: the union of two directories is simply the concatenation of their contents, so a directory listing of the union may display duplicate names. Also, no effort is made to recursively merge subdirectories, leading to an extremely simple implementation.[4] Directories are unioned in a controllable order; u/name, where u is a union directory, denotes the file called name in the first constituent directory that contains such a file.[4]
Unix and BSD
[edit]Unix/POSIX implementations of unions have requirements different from the Plan 9 implementation due to constraints in the traditional Unix file system behavior, which greatly complicates their implementation and often leads to compromises.[5] Problems that union mounting on Unix-like operating systems encounters include:
- Duplicate file names within a directory are not acceptable, since this would break applications' expectations of how a Unix file system works. Putting a logical, stack-like precedence ordering on the union's constituents partially solves this problem, but requires memory to record which files need to be skipped over during a directory listing (which is otherwise a nearly stateless operation).[5]
- Deletion requires special support: if files with the same name exist in several of the union directory's constituents, simply deleting it from one of the constituents causes a file from one of the others to reappear in its stead.[5]
- Insertion of a directory into the stack can cause incoherency in the kernel's file name cache.[5]
- Renaming a file within a single mounted file system (using the rename system call) should be an atomic operation, but renaming within a union mount can require changes to multiple of the union's constituent directories. A possible solution is to disallow rename in such situations and require implementations to copy-and-delete instead.[2]
- Stable inode numbers for files, hard links and memory-mapped I/O (mmap) are hard to implement correctly.[2]
Early attempts to add unioning to Unix filesystems included the 3-d filesystem (Bell Labs) and the Translucent File Service in SunOS (Sun Microsystems, 1988[2]). An implementation of union mounting was added to the BSD version of Unix in version 4.4 (1994), taking inspiration from these earlier attempts, Plan 9 and the stackable file systems in Spring (Sun, 1994).[1] 4.4BSD implements the stack-of-directories approach outlined above. As in Plan 9, operations traverse this stack top-down to resolve names, but unlike Plan 9, BSD union mounts are recursive, so that the contents of subdirectories appear merged in the union directory. Also unlike the Plan 9 version, all layers except the top are read-only: modifying files in the union causes their contents to first be copied into the top layer of the stack, where the modifications are then applied. Deletion of files is implemented by writing a special type of file called a whiteout to the top directory, which has the effect of marking the file name as non-existent and hiding files with the same name in the lower layers of the stack.[1] Whiteouts require support from the underlying file system.[4]
Linux
[edit]Union mounting was implemented for Linux 0.99 in 1993; this initial implementation was called the Inheriting File System, but was abandoned by its developer because of its complexity.[2] The next major implementation was UnionFS, which grew out of the FiST project at Stony Brook University.[6][5] An attempt to replace UnionFS, aufs, was released in 2006, followed in 2009 by OverlayFS.[2] In 2014 OverlayFS union mount implementation was added to the standard Linux kernel source code.[7]
Similarly, GlusterFS offers the ability to mount different filesystems distributed across a network, rather than being located on the same machine.[8]
MergerFS, originally released in 2014, is an actively developed open-source FUSE plugin, allowing pooling of arbitrary directories.[9]
References
[edit]- ^ a b c d Pendry, Jan-Simon; Marshall Kirk McKusick (December 1995). "Union Mounts in 4.4BSD-Lite". Proceedings of the USENIX Technical Conference on UNIX and Advanced Computing Systems: 25–33. Retrieved 25 November 2007.
- ^ a b c d e f Aurora, Valerie; Henson (March 2009). "Unioning file systems: Architecture, features, and design choices". LWN.net. Retrieved 21 December 2009.
- ^ Pike, R.; Presotto, D.; Thompson, K.; Trickey, H.; Winterbottom, P. "The Use of Name Spaces in Plan 9". Random Contrarian Insurgent Organization web site cat-v.org. Bell Labs. Retrieved 27 October 2016.
- ^ a b c Aurora, Valerie; Henson (March 2009). "Union file systems: Implementations, part I". LWN.net. Retrieved 21 December 2009.
- ^ a b c d e Wright, Charles P.; Jay Dave; Puja Gupta; Harikesavan Krishnan; Erez Zadok; Mohammad Nayyer Zubair. "Versatility and Unix Semantics in a Fan-Out Unification File System". Stony Brook University Technical Report FSL-04-01b. Retrieved 25 November 2007.
- ^ Aurora, Valerie; Henson (April 2009). "Unioning file systems: Implementations, part 2". LWN.net. Retrieved 21 December 2009.
- ^ Larabel, Michael (29 September 2014). "OverlayFS Proposed for the Linux 3.18 Kernel". Phoronix.com. Retrieved 12 October 2015.
- ^ "About". GlusterNews. 14 November 2009. Archived from the original on 7 April 2013. Retrieved 4 March 2013.
GlusterFS is an open source, distributed file system capable of scaling to several petabytes (actually, 72 brontobytes!) and handling thousands of clients. GlusterFS clusters together storage building blocks over Infiniband RDMA or TCP/IP interconnect, aggregating disk and memory resources and managing data in a single global namespace. GlusterFS is based on a stackable user space design and can deliver exceptional performance for diverse workloads.
- ^ "MergerFS project on GitHub". github.com. Retrieved 15 September 2021.
Union mount
View on Grokipediafrom Grokipedia
A union mount is a filesystem mounting method used in various operating systems to overlay multiple directories or filesystems, creating a single, unified namespace that transparently combines their contents as if they were stored in one location, with higher-priority layers overriding lower ones where conflicts occur.[1] This technique enables read-write modifications to appear only in the upper layer, preserving the integrity of underlying read-only branches, and is particularly valuable for scenarios requiring layered or virtualized file access without data duplication.[2]
The concept originated in the Plan 9 operating system, where the
This process caches results in the filesystem's dentry structures for efficiency in repeated accesses.[8][10]
Write operations are directed exclusively to the uppermost writable layer to maintain the read-only nature of lower layers. When modifying a file present only in a lower layer, a copy-up mechanism is triggered: the file's data and metadata are duplicated to the upper layer, after which the modification proceeds on the copy. This copy-on-write principle avoids altering immutable lower layers and ensures atomicity during the transition. For directory creations, intermediate directories in the upper layer are built as needed to support the new path. Deletions from lower layers are simulated using whiteout markers—special opaque files or entries (e.g., zero-length files with a
The concept of union mounts has influenced modern container technologies, such as Docker's image layering, which relies on union filesystems like OverlayFS to stack immutable layers for efficient storage and deployment, though Docker layers emphasize persistence and immutability over the dynamic, multi-writable flexibility of traditional unions.[14][12]
bind and mount system calls support union directories through flags like MBEFORE and MAFTER, allowing a new directory to be prepended or appended to an existing one for name resolution, with MCREATE enabling selective writes to writable branches.[3] It was later adopted and refined in Unix-like systems, including 4.4BSD-Lite, where union mounts merge the contents of a mounted filesystem with the existing directory at the mount point, avoiding the traditional hiding of underlying files and instead providing a logical merger visible to users and processes.[4]
In modern implementations, such as Linux's OverlayFS—introduced as a prototype union filesystem in kernel version 3.18—union mounts support multiple lower layers (e.g., read-only directories stacked as /lower1:/lower2), a single upper layer for changes, and mechanisms like "copy-up" for promoting files during modifications, along with whiteouts for deletions.[1] FreeBSD's mount_unionfs utility similarly attaches an upper directory over a lower one, maintaining visibility of both trees while prioritizing the upper for lookups and updates.) These features make union mounts essential for applications like containerization (e.g., Docker images layering changes atop base filesystems), live operating system distributions that overlay temporary writable space on read-only media, and efficient testing environments that isolate modifications without full copies.[2]
Overview
Definition and Purpose
A union mount is a filesystem technique in operating systems that combines multiple directories or filesystems into a single, unified virtual view, where the contents appear merged such that files and directories from all layers are visible simultaneously. In this setup, read operations prioritize the uppermost layer for matching names, falling back to lower layers if not found, while write operations—such as creating or modifying files—typically direct changes to the topmost writable layer to avoid altering underlying read-only components.[5][1][4] The primary purpose of union mounts is to enable non-destructive overlays, allowing modifications to be applied atop immutable base filesystems without duplicating data or risking corruption of originals, which is particularly useful for maintaining system integrity during updates or customizations. This approach supports versioning by preserving historical layers, facilitates the creation of isolated virtual environments akin to containerization, and simplifies merging directory trees for dynamic, live-updating systems. Key benefits include efficient resource use through avoidance of full copies, enhanced flexibility in namespace management, and support for read-only roots with layered changes, as seen in implementations across operating systems like Plan 9, Linux's OverlayFS, and BSD variants.[5][1][4] For instance, union mounts can overlay user-specific configurations onto system-wide defaults, ensuring that personalized settings take precedence without editing core files, thereby streamlining administration in multi-user or distributed environments.[1][4]History
Union mounts originated in Plan 9 from Bell Labs, a distributed operating system developed in the late 1980s by a team including Ken Thompson and Rob Pike to address limitations in traditional Unix-like systems for networked environments. The feature, known as union directories, was implemented using thebind and mount commands to overlay multiple directories into a single namespace, allowing sequential searching of components for flexible resource access; it became operational as part of Plan 9's primary computing environment by 1989.
The concept gained broader adoption in Unix-like systems through its integration into 4.4BSD in 1994, where it was formalized as a union filesystem feature to support merged views of directories for applications like read-only media overlays and user-specific customizations. Developed by Jan-Simon Pendry and Marshall Kirk McKusick, this implementation emphasized namespace management in multi-user settings and influenced subsequent BSD variants.
In Linux, union mount development accelerated in the early 2000s with UnionFS, an initial stackable kernel module effort developed around 2003–2004 by Erez Zadok and his team at Stony Brook University to enable layered filesystems for tasks such as live CDs.[6] This evolved with AUFS (Another Union Filesystem), a 2006 rewrite by Junjiro R. Okajima that enhanced performance and reliability over UnionFS version 1.x, becoming widely used in distributions for its multi-branch support.[7] By 2014, OverlayFS was merged into the Linux kernel mainline in version 3.18 as a simpler, in-kernel union mount solution, marking the transition to a standardized feature in modern distributions.
Technical Details
Mechanism of Operation
Union mounts operate by stacking multiple filesystem branches or directories into a unified namespace, typically organized as layers where an upper (writable) layer overlays one or more lower (often read-only) layers.[4][8] The core mechanism presents a merged view to users and applications, allowing transparent access to files across layers without altering the underlying structures. This layering was first formalized in Plan 9's union directories, where multiple directories are bound into a list and searched in a specified order.[9] For read operations, path resolution follows a priority-based search starting from the topmost (highest-precedence) layer and proceeding downward until a matching file or directory is found. If no match exists in upper layers, the system falls back to lower layers, ensuring that files in higher layers shadow equivalent names in lower ones. Directories are merged similarly, combining entries from all visible layers while eliminating duplicates based on name. A simple algorithmic outline for lookup can be described as follows:function lookup(path):
for layer in layers from top to bottom:
if path exists in layer and not hidden by whiteout:
return layer's entry
return not found
function lookup(path):
for layer in layers from top to bottom:
if path exists in layer and not hidden by whiteout:
return layer's entry
return not found
.wh. prefix or special device nodes) placed in the upper layer to hide the corresponding lower entry from the merged view. Opaque directories serve a similar role for subtrees, preventing visibility of lower directories.[4][8][10]
Handling edge cases varies slightly across implementations but follows consistent principles. Symbolic links are resolved using the leftmost (top) occurrence, without requiring copy-up unless modification is needed. Hard links across layers typically necessitate copy-up to unify references in the upper layer. Permissions are evaluated against the effective layer's attributes, often with stashed credentials to reconcile differences between layers, ensuring consistent access control during operations like copy-up. Conflicts between file types (e.g., a file in the upper layer shadowing a directory in the lower) are resolved by prioritizing the upper layer, potentially leading to errors if incompatible operations are attempted.[8][10]
Comparison to Related Filesystem Techniques
Union mounts differ from overlay filesystems in their support for layering and write operations. While overlay filesystems like OverlayFS typically combine multiple read-only lower layers with a single writable upper layer, where modifications trigger copy-up operations to the upper layer, union mounts—such as those implemented in Unionfs—allow for multiple read-write branches that can be dynamically inserted or deleted, enabling full merging across layers without restricting writability to one layer.[1][11] In contrast to bind mounts, which simply remount an existing directory or subtree at a new location to provide an alternate view of a single filesystem without any merging or prioritization of contents, union mounts actively combine and prioritize elements from multiple distinct sources into a unified namespace.[12][13] Union mounts also diverge from snapshotting mechanisms in filesystems like ZFS or Btrfs, which create point-in-time copies using copy-on-write to enable versioning and rollback without affecting the live system; unions instead facilitate live, non-forking overlays that merge active directories in real time, avoiding the storage overhead of full snapshots while supporting dynamic updates.[12]| Technique | Layering Support | Write Handling | Use in Containers |
|---|---|---|---|
| Union Mount | Multiple layers, including multiple read-write branches | Copy-up or direct merge to prioritized branches | Early implementations influenced layered storage; supports dynamic branch management for flexible isolation |
| OverlayFS | Multiple read-only lower layers + one writable upper layer | Copy-up from lower to upper on modification | Primary driver for Docker images; enables efficient, immutable layer stacking |
| Bind Mount | Single layer (no merging) | Direct access to source filesystem | Host-container directory sharing; no layering or prioritization |
| Snapshot (ZFS/Btrfs) | Point-in-time fork of filesystem | Copy-on-write for changes post-snapshot | Versioning and rollback in container storage; higher overhead for live merges |
Implementations
Plan 9
Plan 9 from Bell Labs provided native support for union mounts as a core feature of its distributed operating system architecture, with the first edition released in 1992.[15] This implementation was integrated into the 9P protocol, which serves as the foundational network-transparent file access mechanism, allowing union directories to seamlessly overlay local and remote filesystems across distributed environments.[16] The design emphasized flexibility in resource aggregation, enabling users to combine directories from multiple sources without disrupting the overall namespace structure. Union mounts in Plan 9 are primarily achieved through thebind command and its underlying system call, which modify the current process's namespace and those of its group. For simple unions, bind replaces or aliases a target directory (old) with a source (new), while flags like -a (append after) and -b (before) extend existing union directories by adding the source's contents to the end or beginning of the search order, respectively. The -c flag enables file creation within the union, directing new files to the first writable component. These operations support multi-directory overlays, creating a unified view where files from overlaid directories are presented transparently, with search precedence determined by the binding order. In Plan 9's namespace-based system, such unions are handled per-process, inheriting across forks unless explicitly controlled, which allows dynamic reconfiguration without system-wide mounts.[9][3]
A key unique aspect of Plan 9's union mounts is their tight integration with per-process namespaces, permitting individualized overlays that do not affect other processes or require global configuration. For instance, users commonly bind remote filesystems under /n/ (for network sources) or /mnt/ (for mounted devices) to create unions, such as overlaying personal binaries onto system directories for customized environments. This approach supports seamless distributed computing, where 9P transactions handle access to unioned components regardless of their local or remote origin. Developed at Bell Labs starting in the mid-1980s by the team behind Unix, these features were crafted to foster flexible, location-independent resource sharing in research-oriented distributed systems.[17]
Union mounts remain a fundamental, largely unchanged element in Plan 9 derivatives like 9front, an actively maintained fork with recent releases as of October 2025.[18]
Unix and BSD Variants
The union mount was introduced in 4.4BSD-Lite in 1994 as the union filesystem (unionfs), a mount-centric mechanism for overlaying directories to form a unified namespace without obscuring underlying content.[19] This implementation, accessed via themount_union command, allows stacking of filesystem branches where the upper layer serves as the writable component atop one or more read-only lower layers.[4] Modifications to files in lower layers trigger a copy-up operation to the upper layer, while deletions are handled through whiteout files—special opaque entries that mask corresponding items below without altering the original filesystems.[19] Early versions lacked support for recursive unions, restricting stacking to non-nested configurations and requiring manual management for deeper hierarchies.[4]
Adoption extended to modern BSD derivatives, including FreeBSD, NetBSD, and OpenBSD, each with tailored variants emphasizing POSIX compliance and global mount tables. In FreeBSD, the mount_unionfs command provides the primary interface, often paired with nullfs for straightforward bind mounts that lack unioning semantics.[20] NetBSD and OpenBSD retained the mount_union syntax from 4.4BSD, with NetBSD's kernel-integrated unionfs incorporating performance tweaks such as optimized caching for branch traversals to reduce lookup overhead in multi-layer setups. Command usage typically follows the form mount -t unionfs [options] upperdir uniondir, where options like -o below adjust visibility priorities across branches.[20]
Post-2000 releases addressed historical bugs, including race conditions in locking and mount ordering issues that could lead to filesystem inconsistencies or privilege escalations. For instance, FreeBSD fixed several unionfs ambiguities and concurrency problems persisting until version 6.2 in 2006.[21] Similar refinements in NetBSD and OpenBSD stabilized whiteout handling and copy-up reliability, enhancing robustness for production environments.[22] These variants differ subtly: NetBSD emphasizes tunable performance for high-load scenarios, while OpenBSD prioritizes security hardening in whiteout creation to prevent namespace leaks. Unionfs continues to be maintained in FreeBSD, with an update to version 3.7 as of October 2025.[23]
A common usage example involves overlaying local customizations on a base system directory, such as mounting /usr/local atop /usr to add user binaries without modifying the original tree: mount -t [unionfs](/page/UnionFS) -o upper=/usr/local /usr /usr. This preserves access to base files while prioritizing local overrides, ideal for development or site-specific extensions.[20] The BSD union mount's design, influenced by Plan 9's union directories, maintains Unix semantics in a global namespace, contrasting per-process approaches in other systems.
Linux
Union mount support in Linux began with out-of-tree kernel modules in the early 2000s, notably Unionfs, which provided a stackable unification filesystem for merging multiple directories (branches) into a single view while preserving their physical separation.[24] Unionfs, initially released around 2004, operated as a loadable module that intercepted filesystem operations to enable features like read-write overlays on read-only branches.[25] This implementation drew inspiration from earlier union mount concepts in BSD systems but adapted them for Linux's modular kernel architecture.[6] In 2006, AUFS (Advanced Union Filesystem) emerged as a reimplementation and enhancement of Unionfs, introducing improved branch management, dynamic policy-based selection of branches, and better performance for multi-layered stacking.[7] AUFS supported arbitrary numbers of branches with read-write capabilities on upper layers and was widely adopted in distributions for live environments and container storage before kernel mainline integration of alternatives.[26] However, both Unionfs and AUFS remained out-of-tree and were eventually deprecated in favor of in-kernel solutions; Unionfs development stalled, and AUFS was not merged due to maintenance concerns.[27] The modern standard for union mounts in Linux is OverlayFS, which was merged into the kernel in version 3.18 in December 2014, providing a lightweight, native implementation focused on simplicity and efficiency.[1] OverlayFS supports overlaying a read-only lower directory onto a writable upper directory, using copy-on-write semantics where modifications are stored only in the upper layer to avoid altering the lower one.[1] Key features include whiteout support for hiding lower-layer files, implemented via extended attributes such as "trusted.overlay.whiteout" on zero-sized files or special character devices, and compatibility with diverse underlying filesystems.[1] Mount options include "lowerdir" for specifying one or more read-only layers (separated by colons for multiples) and "upperdir" for the writable overlay, requiring a separate "workdir" on the same filesystem as upperdir for temporary operations.[1] For user-space alternatives, tools like unionfs-fuse provide FUSE-based union mounts, allowing flexible overlaying of directories without kernel modifications, though with potential performance overhead compared to in-kernel OverlayFS.[28] OverlayFS is now the preferred implementation in major distributions, such as Ubuntu, where it is used via packages like overlayroot to create writable chroot environments over read-only root filesystems.[29] An example mount command is:mount -t overlay overlay -o lowerdir=/base,upperdir=/mods /union, which combines the read-only /base with writable modifications in /mods at the /union mount point.[1]