Lines Matching full:overlay
6 Overlay Filesystem
10 overlay-filesystem functionality in Linux (sometimes referred to as
11 union-filesystems). An overlay-filesystem tries to present a
16 Overlay objects
19 The overlay filesystem approach is 'hybrid', because the objects that
25 While directories will report an st_dev from the overlay-filesystem,
32 In the special case of all overlay layers on the same underlying
33 filesystem, all objects will report an st_dev from the overlay
35 make the overlay mount more compliant with filesystem scanners and
36 overlay objects will be distinguishable from the corresponding
39 On 64bit systems, even if all overlay layers are not on the same
45 the underlying inode number does overflow into the high xino bits, overlay
48 The "xino" feature can be enabled with the "-o xino=on" overlay mount option.
50 for overlay filesystem objects is not only unique, but also persistent over
51 the lifetime of the filesystem. The "-o xino=auto" overlay mount option
54 The following table summarizes what can be expected in different overlay
86 An overlay filesystem combines two filesystems - an 'upper' filesystem
106 A read-only overlay of two read-only filesystems may use any
123 mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
131 is cached in the dentry belonging to the overlay filesystem. If both
144 filesystem, an overlay filesystem needs to record in the upper filesystem
149 as a zero-size regular file with the xattr "trusted.overlay.whiteout".
155 A directory is made opaque by setting the xattr "trusted.overlay.opaque"
161 "trusted.overlay.whiteout", should be additionally marked by setting the xattr
162 "trusted.overlay.opaque" to "x" on the merge directory itself.
163 This is needed to avoid the overhead of checking the "trusted.overlay.whiteout"
211 copied up (but not the contents). Then the "trusted.overlay.redirect"
213 root of the overlay. Finally the directory is moved to the new
228 Module options (can also be changed through /sys/module/overlay/parameters/):
251 upper directory is stored in a "trusted.overlay.upper" extended attribute
259 NFS export support on an overlay filesystem with no upper layer requires
285 Once the copy_up is complete, the overlay filesystem simply
288 overlay filesystem (though an operation on the name of the file such as
295 Permission checking in the overlay filesystem follows these principles:
299 2) task creating the overlay mount MUST NOT gain additional privileges
301 3) non-mounting task MAY gain additional privileges through the overlay,
325 mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,... /merged
342 mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
345 that case the overlay will be read-only.
354 mount -t overlay overlay -olowerdir=/a\:lower\:\:dir /merged
422 mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged
464 fs-verity enabled and overlay verity support is enabled, then the
465 digest of the lower file is added to the "trusted.overlay.metacopy"
510 Lower layers may be shared among several overlay mounts and that is indeed
511 a very common practice. An overlay mount may use the same lower layer
512 path as another overlay mount and it may use a lower layer path that is
513 beneath or above the path of another overlay lower layer path.
516 another overlay mount is not allowed and may fail with EBUSY. Using
519 upper layer and/or workdir path the behavior of the overlay is undefined,
522 Mounting an overlay using an upper layer path, where the upper layer path
523 was previously used by another mounted overlay in combination with a
529 filesystem, are encoded and stored in the "trusted.overlay.origin" extended
542 It is quite a common practice to copy overlay layers to a different
552 that have overlayfs attributes, such as whiteouts or "overlay.*" xattrs, will
557 "overlay.overlay.". So, a file with a "trusted.overlay.overlay.metacopy" xattr
559 "trusted.overlay.metacopy" xattr in the overlayfs mount. This can be nested by
565 file with the "overlay.whiteout" xattr set, inside a directory with the
566 "overlay.opaque" xattr set to "x" (see `whiteouts and opaque directories`_).
618 underlying filesystem for all layers making up the overlay.
625 overlay filesystem and the value of st_ino for filesystem objects may not be
626 persistent and could change even while the overlay filesystem is mounted, as
633 Changes to the underlying filesystems while part of a mounted overlay
635 the behavior of the overlay is undefined, though it will not result in
638 Offline changes, when the overlay is not mounted, are allowed to the
642 features has been used, the behavior of the overlay is undefined,
645 When the overlay NFS export feature is enabled, overlay filesystems
651 attribute "trusted.overlay.origin" on the upper inode.
655 to by the "trusted.overlay.redirect" extended attribute, will verify
667 feature is enabled, an overlay filesystem may be exported to NFS.
674 "trusted.overlay.upper" with an encoded file handle of the upper
677 When encoding a file handle from an overlay filesystem object, the
685 The encoded overlay file handle includes:
692 are stored in extended attribute "trusted.overlay.origin".
694 When decoding an overlay file handle, the following steps are followed:
700 overlay object that was deleted after its file handle was encoded.
701 5. For a non-directory, instantiate a disconnected overlay dentry from the
704 and index, to lookup a connected overlay dentry.
710 When overlay filesystem has multiple lower layers, a middle layer
716 reconstruct a connected overlay path. To mitigate the cases of
719 On an overlay filesystem with no upper layer this mitigation cannot be
723 The overlay filesystem does not support non-directory connectable file
754 UUID is stored in xattr "trusted.overlay.uuid", making overlayfs fsid
758 UUID is taken from xattr "trusted.overlay.uuid" if it exists.
759 Upgrade to "uuid=on" on first time mount of new overlay filesystem that
761 Downgrade to "uuid=null" for existing overlay filesystems that were never
770 mounts are only used if data written to the overlay can be recreated
784 When overlay is mounted with "volatile" option, the directory
785 "$workdir/work/incompat/volatile" is created. During next mount, overlay
797 "user.overlay." xattr namespace instead of "trusted.overlay.". This is