

Storage Scalability in Docker - rbanffy
http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/?utm_content=buffer8a955&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

======
asb
It's a real shame that there's no comparison with aufs as a baseline. They
discount it for not being in mainline, but of course neither is overlayfs. The
overlayfs author has been trying for upstream inclusion for years, maybe he'll
see luck with his request for inclusion in 3.18:
[https://lkml.org/lkml/2014/9/29/350](https://lkml.org/lkml/2014/9/29/350)

~~~
riffraff
Also, why isn't the solution "push for inclusion of aufs in upstream"? Red Hat
should have some non-zero weight in kernel decisions, methinks.

~~~
otterley
I suspect it's because Red Hat believes overlayfs is superior to aufs and so
they'd rather advocate for that solution.

~~~
asb
Well, it's more likely to get in given that nobody is really pushing aufs any
more. overlayfs is less ambitious and less featureful, which can of course be
a big advantage when trying to get it in to the kernel.

------
jude-
OverlayFS’s speedup comes in part “by allowing the kernel to include only a
single copy of a file read from multiple containers in it’s page cache.” I’m
concerned that this could be a source of information leaks across containers.

Suppose container A reads a page from a file whose contents are shared with
container B’s image. Container B can use the shared page cache to deduce when
container A has read the file (and deduce which pages) by periodically reading
the corresponding file in its root FS and recording how fast the kernel can
serve it the page in question. Moreover, if the cache implementation is
content addressable (i.e. the kernel determines a cache hit based on the hash
of the page’s contents), B can guess the contents of A’s secret files’ pages
by writing its guesses to a file and then reading them and recording how
quickly the kernel serves them back.

Does OverlayFS (or some other system, like SELinux) mitigate these concerns?

~~~
justincormack
It is not content based (well there might have been some dedup code available
but you can disable it). The main thing is actually sharing shared libraries,
and binaries. Which are I dont think a security risk.

~~~
e12e
Well... one might time how long it takes to load various patch-levels of...
say the bash binary? And so deduce if another container is running known-
vulnerable code, to later leverage that in a spearfishing attack.

------
justincormack
ZFS is also being worked on as a Docker storage layer
[https://github.com/ClusterHQ/flocker](https://github.com/ClusterHQ/flocker)

~~~
bjt
As I understand it, the Flocker guys aren't really working on the CoW
filesystem part of Docker, but solving the problems of data locality and
persistence with regular (non-CoW) volumes mounted into a container.

~~~
lewq
That's correct - at ClusterHQ (makers of Flocker) we are focusing on using ZFS
for volumes. ZFS itself is a copy-on-write filesystem, but we're using
snapshots so that we can do send/recv between hosts, as opposed to using
snapshots for the layers in a Docker image.

Separately to the work we're doing, the guys at Gandi (a European hosting
company) are working on ZFS support for Docker images - see
[https://github.com/docker/docker/pull/7901](https://github.com/docker/docker/pull/7901)

Combining these two efforts could result in a pure ZFS-on-root Docker
distribution, which uses ZFS with Flocker for volumes, _and_ ZFS for the
Docker images themselves. That would be pretty cool, IMHO. ;)

