From f2ef46243a337eeae842aa18a23b0b19a52c584b Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 19 Mar 2026 17:01:52 +0100 Subject: [PATCH] docs: fix duplicate headings in overlayfs driver page 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 --- .../storage/drivers/overlayfs-driver.md | 40 +++++++++---------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/content/manuals/engine/storage/drivers/overlayfs-driver.md b/content/manuals/engine/storage/drivers/overlayfs-driver.md index 692ea080e830..cdec2f68258f 100644 --- a/content/manuals/engine/storage/drivers/overlayfs-driver.md +++ b/content/manuals/engine/storage/drivers/overlayfs-driver.md @@ -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`). - - `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`. +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`. [`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.