Enable overlayfs options that make it act more like a standards compliant filesystem
Quote from the “Non-standard behavior” section of the overlayfs documentation :
The following options allow overlayfs to act more like a standards compliant filesystem: 1) "redirect_dir" Enabled with the mount option or module option: "redirect_dir=on" or with the kernel config option CONFIG_OVERLAY_FS_REDIRECT_DIR=y. If this feature is disabled, then rename(2) on a lower or merged directory will fail with EXDEV ("Invalid cross-device link"). 2) "inode index" Enabled with the mount option or module option "index=on" or with the kernel config option CONFIG_OVERLAY_FS_INDEX=y. 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. 3) "xino" Enabled with the mount option "xino=auto" or "xino=on", with the module option "xino_auto=on" or with the kernel config option CONFIG_OVERLAY_FS_XINO_AUTO=y. Also implicitly enabled by using the same underlying filesystem for all layers making up the overlay. If this feature is disabled or the underlying filesystem doesn't have enough free bits in the inode number, then overlayfs will not be able to guarantee that the values of st_ino and st_dev returned by stat(2) and the value of d_ino returned by readdir(3) will act like on a normal filesystem. E.g. the value of st_dev may be different for two objects in the same overlay filesystem and the value of st_ino for directory objects may not be persistent and could change even while the overlay filesystem is mounted.
IMO we should try to enable these options, if they work in our use case.
Feature Branch: feature/17258-enable-overlayfs-features+force-all-tests
- Related to #8415 (closed)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information