centersl/docker-docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-03-27 14:28:47 +07:00
Code Issues Packages Projects Releases Wiki Activity

docs: fix duplicate headings in overlayfs driver page

Browse Source 
Rename the second "Image and container layers on-disk" section heading to
"Image and container layers on-disk (legacy overlay driver)" to distinguish
it from the overlay2 section above it. Fixes #18191.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
David Karlsson
2026-03-19 17:01:52 +01:00
parent 6b1ebe4fba
commit f2ef46243a
1 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
content/manuals/engine/storage/drivers/overlayfs-driver.md
View File

@@ -224,7 +224,7 @@ the image's top layer plus a new directory for the container. The image's
layers are the `lowerdirs` in the overlay and are read-only. The new directory for
the container is the `upperdir` and is writable.
### Image and container layers on-disk
### Image and container layers on-disk (legacy overlay driver)
The following `docker pull` command shows a Docker host downloading a Docker
image comprising five layers.
@@ -442,25 +442,25 @@ filesystems:
[`open(2)`](https://linux.die.net/man/2/open)
: OverlayFS only implements a subset of the POSIX standards.
This can result in certain OverlayFS operations breaking POSIX standards. One
such operation is the copy-up operation. Suppose that your application calls
`fd1=open("foo", O_RDONLY)` and then `fd2=open("foo", O_RDWR)`. In this case,
your application expects `fd1` and `fd2` to refer to the same file. However, due
to a copy-up operation that occurs after the second calling to `open(2)`, the
descriptors refer to different files. The `fd1` continues to reference the file
in the image (`lowerdir`) and the `fd2` references the file in the container
(`upperdir`). A workaround for this is to `touch` the files which causes the
copy-up operation to happen. All subsequent `open(2)` operations regardless of
read-only or read-write access mode reference the file in the
container (`upperdir`).
This can result in certain OverlayFS operations breaking POSIX standards. One
such operation is the copy-up operation. Suppose that your application calls
`fd1=open("foo", O_RDONLY)` and then `fd2=open("foo", O_RDWR)`. In this case,
your application expects `fd1` and `fd2` to refer to the same file. However, due
to a copy-up operation that occurs after the second calling to `open(2)`, the
descriptors refer to different files. The `fd1` continues to reference the file
in the image (`lowerdir`) and the `fd2` references the file in the container
(`upperdir`). A workaround for this is to `touch` the files which causes the
copy-up operation to happen. All subsequent `open(2)` operations regardless of
read-only or read-write access mode reference the file in the
container (`upperdir`).
`yum` is known to be affected unless the `yum-plugin-ovl` package is installed.
If the `yum-plugin-ovl` package is not available in your distribution such as
RHEL/CentOS prior to 6.8 or 7.2, you may need to run `touch /var/lib/rpm/*`
before running `yum install`. This package implements the `touch` workaround
referenced above for `yum`.
`yum` is known to be affected unless the `yum-plugin-ovl` package is installed.
If the `yum-plugin-ovl` package is not available in your distribution such as
RHEL/CentOS prior to 6.8 or 7.2, you may need to run `touch /var/lib/rpm/*`
before running `yum install`. This package implements the `touch` workaround
referenced above for `yum`.
[`rename(2)`](https://linux.die.net/man/2/rename)
: OverlayFS does not fully support the `rename(2)` system call. Your
application needs to detect its failure and fall back to a "copy and unlink"
strategy.
application needs to detect its failure and fall back to a "copy and unlink"
strategy.