Docker project: Can you have overlay2 speed and density with devicemapper? Yep.

[Jeremy Eder]

Hi,

Vivek Goyal (cc) and I were discussing ways to deliver page cache sharing, POSIX compliance and SELinux support with a single docker graph driver, using existing kernel facilities.  We decided to go with a bind-mount technique, and Vivek has posted a first cut here:  https://github.com/docker/docker/pull/27364​

Testing of the prototype looks like a great improvement:

​http://developerblog.redhat.com/2016/10/25/docker-project-can-you-have-overlay2-speed-and-density-with-devicemapper-yep/

Assuming this type of feature is merged in a container run-time, what preference would Kube folks have for surfacing this to users ... currently it's a daemon runtime flag that says ... if you use --read-only then you get the shared-rootfs as well.  Obviously this requires "12factor-ish" design up front, because you can no longer scribble in the container filesystem in places that are not persistent volumes, but we think read-only container hygiene is well worth the security and performance improvements to be had.

https://twitter.com/rhdevelopers/status/790870667008757760

[Vishnu Kannan]

*What* do you intend to surface to users? IIUC, this discussion is specific to device mapper storage drivers right?

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CABxNGQa-VLzP%3DEFYQucfJtTEtSHmWac4Tv%3Dc%2BQVAFJNcDLSb1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Eder]

​If a user specifies read-only in their podspec...what does that translate to (it might be a distro-specific question).  IMO the --shared-rootfs should be the default when --read-only is specified, but it's not atm.

Vivek has implemented it for devicemapper first.  But the intent is that it will be added to most or all graph drivers, including overlay/overlay2.  It has the most benefit on devicemapper or btrfs which have unique inodes per container.

On Wed, Oct 26, 2016 at 2:20 PM, Vishnu Kannan <vis...@google.com> wrote:

*What* do you intend to surface to users? IIUC, this discussion is specific to device mapper storage drivers right?

On Tue, Oct 25, 2016 at 5:03 AM, Jeremy Eder <je...@redhat.com> wrote:

Hi,

Vivek Goyal (cc) and I were discussing ways to deliver page cache sharing, POSIX compliance and SELinux support with a single docker graph driver, using existing kernel facilities.  We decided to go with a bind-mount technique, and Vivek has posted a first cut here:  https://github.com/docker/docker/pull/27364​

Testing of the prototype looks like a great improvement:

​http://developerblog.redhat.com/2016/10/25/docker-project-can-you-have-overlay2-speed-and-density-with-devicemapper-yep/

Assuming this type of feature is merged in a container run-time, what preference would Kube folks have for surfacing this to users ... currently it's a daemon runtime flag that says ... if you use --read-only then you get the shared-rootfs as well.  Obviously this requires "12factor-ish" design up front, because you can no longer scribble in the container filesystem in places that are not persistent volumes, but we think read-only container hygiene is well worth the security and performance improvements to be had.

https://twitter.com/rhdevelopers/status/790870667008757760

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.

To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CABxNGQa-VLzP%3DEFYQucfJtTEtSHmWac4Tv%3Dc%2BQVAFJNcDLSb1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

-- Jeremy Eder

[Mrunal Patel]

IMO, this doesn't really need any new knobs in the pod spec. This could be handled under the hood in the container runtime level (by config or default).

[Clayton Coleman]

Yeah it sounds like it - that's a good place to start, and then if we realize we need the knob we can come back and decide on an API object change if necessary.

To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CANEZBD4zd%3Dk-m2B2rK5Eixv_%2BfY3tFqSgJa%2BaemW4f4fj5g3Bg%40mail.gmail.com.