Why did my docker using overlay2 as its storage driver?

In the above article, it says “Note: If you use OverlayFS, use the overlay2 driver rather than the overlay driver, because it is more efficient in terms of inode utilization. To use the new driver, you need version 4.0 or higher of the Linux kernel, unless you are a Docker EE user on RHEL or CentOS, in which case you need version 3.10.0-693 or higher of the kernel and to follow some extra steps.”

Question: is the documentation saying that overlayfs2 is exclusively for EE or for both EE and CE for needing kernel version 3.10.0-693?

well, im on kernel 3.10.0-693 on rhel7.4 using docker version 18.03.0-ce
I am not on EE yet, i am still able to use overlay2 or is this not something supported uner 18.03.0-ce and i need to change the storage driver to devicemapper

uname -r

3.10.0-693.17.1.el7.x86_64

cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.4 (Maipo)

docker version

Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:09:15 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm

Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:13:03 2018
OS/Arch: linux/amd64
Experimental: false](http://)

The documentation actually states

The overlay2 driver is supported for Docker EE and recommended for Docker CE.

So it is used for CE as well.

Also in Docker storage drivers | Docker Docs

overlay2 is preferred, followed by overlay. Neither of these requires extra configuration. overlay2 is the default choice for Docker CE.

please visit https://docs.docker.com/storage/storagedriver/overlayfs-driver/

it has a big greyed-out block item, i qoute

“Note: If you use OverlayFS, use the overlay2 driver rather than the overlay driver, because it is more efficient in terms of inode utilization. To use the new driver, you need version 4.0 or higher of the Linux kernel, unless you are a Docker EE user on RHEL or CentOS, in which case you need version 3.10.0-693 or higher of the kernel and to follow some extra steps.”

“unless you are a Docker EE user” should be a Docker EE/CE user

I think it is implying that that Docker CE on Linux 3.x is not supported in the given configuration. It does not say it won’t work, you just won’t get any support if you have any issues. EE paid customers may be locked down on their version of Linux so they would be paying for that extra support to get it working in their environment.

my point exactly is that if it’s not supported docker-ce then why is it defaulting to overlay2 when i stall docker ce… which means i have to do extra work just to convert to something else

Maybe it’s the phrasing of it, but my understanding of the document as a whole (not just that blurb) is overlay2 is used and is supported on CE, but overlay is not supported on CE. You can probably add a request to change it but putting in EE/CE isn’t right as it would imply that CE is supported with the overlay driver.

i am sorry to be blunt but “that blurb” is specifically talking about overlay2 if you read it. so the request to change it by putting EE/CE is is right because it is only referring to overlay2

Note: If you use OverlayFS, use the overlay2 driver rather than the overlay driver, because it is more efficient in terms of inode utilization. To use the new driver, you need version 4.0 or higher of the Linux kernel, unless you are a Docker EE user on RHEL or CentOS, in which case you need version 3.10.0-693 or higher of the kernel and to follow some extra steps.

“it” and the “new driver” where the conditions are being defined in the paragraph is for overlay2

This is how I parsed it in my head.

Clause 1.

If you use OverlayFS, then 
   use the overlay2 driver rather than the overlay driver, \
     because it is more efficient in terms of inode utilization. 
end if.

Second clause…

a = Linux kernel version >= 4.0
b = docker EE user on RHEL or CentOS
c = Linux kernel version >= 3.10.0-693 
d = want To use the new driver
e = `overlay2` driver is supported.

d -> a xor (b && c) -> e

Now if “d” is true which generally we want it to be true otherwise we won’t care. That means the following must be true.

a xor (b && c) → e

If a xor (b && c) is true then e must be true so the driver is supported if their conditions are met.

If a xor (b && c) is false then e is not relevant, as the situation is not explicitly specified or supported.

So their documentation itself is right. What they can explicitly state though is overlay is not supported on Docker CE. Which basically adds an extra guard condition to their statement to indicate when the driver is not supported.

Also something that is not supported does not mean it won’t work, it just means they don’t have to help you if it does not work. Since they never claimed it will work in that situation.

However, you can make a issue or PR with them to update that documentation I think they have a link that will allow you to do that.

unfortunately, your logic is wrong as you completely re-hacked the sentence, “To use the new driver, you need version 4.0 or higher of the Linux kernel, unless you are a Docker EE user on RHEL or CentOS, in which case you need version 3.10.0-693 or higher of the kernel and to follow some extra steps.” where the new driver is referring to overlay2

The source of confusion is not that whether this statement is right or not, but rather because it is not inclusive to Docker CE. If you fail to see this, then there is no point continuing this convo

Docker CE Overlay 2 Driver Source Code

@eugenepark3 I agree the documentation is ambiguous. docker info should show you the driver currently in use. The source code for Docer CE Overlay2 driver seems to indicate if you’re running the kernel version 4.0 or later it should just work. I believe it’s possible to use overlay2 with RHEL on 3.10 as well, but maybe that’s when you need to be using Docker EE. Eitherway, the source code seem to show a check that Docker will try out the features needed by it’s Overlay2 driver when the driver is initialising in the daemon init. My advice is to try it and see what docker info spits out. Of course, this is like 3 years late in reply so… Hopefully you figured it out.