Overlayfs Details: Redirects, Indexing, UUIDs, and NFS Export

"redirect_always_follow" feature is enabled in the kernel/module config. follow Redirects are not created, but followed. nofollow Redirects are not created and not followed (equivalent to "redirect_dir=off" if "redirect_always_follow" feature is not enabled). index={on|off} Inode index. If this feature is disabled and a file with multiple hard links is copied up, then this will "break" the link. Changes will not be propagated to other names referring to the same inode. uuid={on|off} Can be used to replace UUID of the underlying filesystem in file handles with null, and effectively disable UUID checks. This can be useful in case the underlying disk is copied and the UUID of this copy is changed. This is only applicable if all lower/upper/work directories are on the same filesystem, otherwise it will fallback to normal behaviour. nfs_export={on|off} When the underlying filesystems supports NFS export and the "nfs_export" feature is enabled, an overlay filesystem may be exported to NFS. With the "nfs_export" feature, on copy_up of any lower object, an index entry is created under the index directory. The index entry name is the hexadecimal representation of the copy up origin file handle. For a non-directory object, the index entry is a hard link to the upper inode. For a directory object, the index entry has an extended attribute "{trusted|user}.overlay.upper" with an encoded file handle of the upper directory inode. When encoding a file handle from an overlay filesystem object, the following rules apply • For a non-upper object, encode a lower file handle from lower inode • For an indexed object, encode a lower file handle from copy_up origin • For a pure-upper object and for an existing non-indexed upper object, encode an upper file handle from upper inode The encoded overlay file handle includes • Header including path type information (e.g. lower/upper) • UUID of the underlying filesystem • Underlying filesystem encoding of underlying inode This encoding format is identical to the encoding format of file handles that are stored in extended attribute "{trusted|user}.overlay.origin". When decoding an overlay file handle, the following steps are followed • Find underlying layer by UUID and path type information. • Decode the underlying filesystem file handle to underlying dentry. • For a lower file handle, lookup the handle in index directory by name. • If a whiteout is found in index, return ESTALE. This represents an overlay object that was deleted after its file handle was encoded. • For a non-directory, instantiate a disconnected overlay dentry from the decoded underlying dentry, the path type and index inode, if found. • For a directory, use the connected underlying decoded dentry, path type and index, to lookup a connected overlay dentry. Decoding a non-directory file handle may return a disconnected dentry. copy_up of that disconnected dentry will create an upper index entry with no upper alias. When overlay filesystem has multiple lower layers, a middle layer directory may have a "redirect" to lower directory. Because middle layer

This section continues detailing overlayfs mount options, focusing on redirect directory behaviors, inode indexing, UUID handling, and NFS export capabilities. It explains the nuances of the `redirect_dir` option, detailing how redirects are created and followed. It describes how disabling inode indexing can break hard links during copy-up. The `uuid` option facilitates UUID replacement for copied disks. The `nfs_export` option describes the considerations and procedures for exporting an overlay filesystem via NFS, including how file handles are encoded and decoded, referencing underlying layers via UUIDs and index directories. It mentions the complexities of handling redirects in multi-layer overlayfs setups.