-
Notifications
You must be signed in to change notification settings - Fork 5
Overlayfs non standard behavior
Overlayfs exhibits some known issues of non-standard file system behavior. The following issues are taken from the Overlayfs overview Non standard behavior section. Solutions to some of these issues are in different stages of development.
rename(2) on a lower or merged directory will fail with EXDEV.
- The redirect_dir feature that fixes this issue was merged in kernel v4.10
- A test option run --ov=N was added to unionmount-testsuite to verify correctness of dir rename with and without overlay layers rotating.
The copy up file may be on a different filesystem, so both st_dev and st_ino of the file may change. This unexpected behavior breaks a few user program, such as yum and tar.
- The origin file handle feature fixes this issue
- Fixes for the setup of all layers on the same filesystem were merged in kernels v4.12 and 4.14
- Fixes for the setup of not all layers on the same filesystem were merged in kernels v4.15 and v4.17
- A test option --verify was added to unionmount-testsuite to verify constant inode numbers across copy up
- The xfstests overlay/017 and overlay/043 were added to cover this issue for same and non-same filesystem setup
If 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.
- The index feature that fixes this issue was merged in kernel v4.13
- The xfstests overlay/018 and overlay/044 were added to cover this issue for same and non-same filesystem setup
The copy_up operation essentially creates a new, identical file and moves it over to the old name. Any files that were open for read before the copy up will continue to access the old data.
- A fix for the case of read(2) was merged in kernel v4.19
- Data accessed via a MAP_SHARED|PROT_READ mapped file may still access the old data
- The xfstests overlay/016 and overlay/061 were added to cover both flavors the issue