Overlayfs and Reiserfs Mount Options: Metacopy, Volatile, and Reiserfs Specific Parameters

https://docs.kernel.org/filesystems/overlayfs.html metacopy={on|off} When metadata only copy up feature is enabled, overlayfs will only copy up metadata (as opposed to whole file), when a metadata specific operation like chown/chmod is performed. Full file will be copied up later when file is opened for WRITE operation. In other words, this is delayed data copy up operation and data is copied up when there is a need to actually modify data. volatile Volatile mounts are not guaranteed to survive a crash. It is strongly recommended that volatile mounts are only used if data written to the overlay can be recreated without significant effort. The advantage of mounting with the "volatile" option is that all forms of sync calls to the upper filesystem are omitted. In order to avoid a giving a false sense of safety, the syncfs (and fsync) semantics of volatile mounts are slightly different than that of the rest of VFS. If any writeback error occurs on the upperdir’s filesystem after a volatile mount takes place, all sync functions will return an error. Once this condition is reached, the filesystem will not recover, and every subsequent sync call will return an error, even if the upperdir has not experience a new error since the last sync call. When overlay is mounted with "volatile" option, the directory "$workdir/work/incompat/volatile" is created. During next mount, overlay checks for this directory and refuses to mount if present. This is a strong indicator that user should throw away upper and work directories and create fresh one. In very limited cases where the user knows that the system has not crashed and contents of upperdir are intact, The "volatile" directory can be removed. Mount options for reiserfs Reiserfs is a journaling filesystem. conv Instructs version 3.6 reiserfs software to mount a version 3.5 filesystem, using the 3.6 format for newly created objects. This filesystem will no longer be compatible with reiserfs 3.5 tools. hash={rupasov|tea|r5|detect} Choose which hash function reiserfs will use to find files within directories. rupasov A hash invented by Yury Yu. Rupasov. It is fast and preserves locality, mapping lexicographically close file names to close hash values. This option should not be used, as it causes a high probability of hash collisions. tea A Davis-Meyer function implemented by Jeremy Fitzhardinge. It uses hash permuting bits in the name. It gets high randomness and, therefore, low probability of hash collisions at some CPU cost. This may be used if EHASHCOLLISION errors are experienced with the r5 hash. r5 A modified version of the rupasov hash. It is used by default and is the best choice unless the filesystem has huge directories and unusual file-name patterns. detect Instructs mount to detect which hash function is in use by examining the filesystem being mounted, and to write this information into the reiserfs superblock. This is only useful on the first mount of an old format filesystem. hashed_relocation Tunes the block allocator. This may provide performance improvements in some situations. no_unhashed_relocation Tunes the block allocator. This may provide performance improvements in some situations. noborder Disable the border allocator algorithm

This section details the `metacopy` and `volatile` mount options for Overlayfs, explaining the delayed data copy-up behavior of `metacopy` and the performance implications and risks associated with `volatile` mounts, including error handling and the creation of an 'incompat/volatile' directory. It also describes the `conv` and `hash` mount options for Reiserfs filesystems, including the different hash functions (rupasov, tea, r5, detect) and allocator tuning options (hashed_relocation, no_unhashed_relocation, noborder).