Closed philips closed 8 years ago
After a test, it seems opq
is actually used here.
We have the following Dockerfile:
FROM alpine
RUN mkdir -p /a/b/c
RUN rm -rf /a/b/c && mkdir -p /a/b/c && touch /a/b/c/foo
Then, save the image output and have a peak at their contents:
--c3a721099f9b631112dd5111e80ec7cd0d61156e7f697750149587e53c401a1f/layer.tar
drwxr-xr-x 0 0 0 0 Jun 22 09:38 a/
drwxr-xr-x 0 0 0 0 Jun 22 09:38 a/b/
drwxr-xr-x 0 0 0 0 Jun 22 09:38 a/b/c/
--e349ceb29a585557791f68cd518355cc0817680fc6876eeea94759bdc59d5cf0/layer.tar
drwxr-xr-x 0 0 0 0 Jun 22 10:30 a/
drwxr-xr-x 0 0 0 0 Jun 22 10:30 a/b/
drwxr-xr-x 0 0 0 0 Jun 22 10:30 a/b/c/
-r--r--r-- 0 0 0 0 Jun 22 10:30 a/b/c/.wh..wh..opq
-rw-r--r-- 0 0 0 0 Jun 22 10:30 a/b/c/foo
Basically, this plays the role of clearing the lower levels directory entries and needs to be covered in the specification.
Note, that I tested this on Docker with AUFS. We should probably solicit a few more tests to confirm this behavior is consistent.
Note, that I tested this on Docker with AUFS.
Using overlay
here I don't get the opq
file:
$ tar tf 79ca28a51cd4dba1117102719f9792a025ab2b203134eeb04b596b16fdcfb740/layer.tar
a/
a/b/
a/b/c/
$ tar tf cd26e349a52917a79a01da873909ca2b185cb845e1c478cc2faa7fc5e0466635/layer.tar
a/
a/b/
a/b/c/
a/b/c/foo
on btrfs, it looks the same as @runcom output
@vbatts @runcom Do these get the correct result?
The following might be a better test:
FROM alpine
RUN mkdir -p /a/b/c && touch /a/b/c/baz
RUN rm -rf /a/b/c && mkdir -p /a/b/c && touch /a/b/c/foo
@stevvooe yes on overlay:
$ tar tf 350bf6a20bd648c11007552fecb7e3a0bdc2edbf98d8f5c6a78094a84f9f6fe2/layer.tar
a/
a/b/
a/b/c/
a/b/c/baz
$ tar tf e605a663b8944626dbfc4cb761506ea996f19b65d9c3ad292ec417179c3a2f4b/layer.tar
a/
a/b/
a/b/c/
a/b/c/.wh.baz
a/b/c/foo
@runcom Thanks you so much for the testing!!
One more test case:
FROM alpine
RUN mkdir -p /a/b/c && touch /a/b/c/baz /a/b/c/boo /a/b/c/bak
RUN rm -rf /a/b/c && mkdir -p /a/b/c && touch /a/b/c/foo
I still get the following with AUFS:
$ tar tf 4d7b3ac6a813e5382c042ff5eaef71fd8f7a54b78ccfa09b948bf21927b64209/layer.tar
a/
a/b/
a/b/c/
a/b/c/.wh..wh..opq
a/b/c/foo
My guess is that we need to support both but favor one for generation.
@stevvooe building your latest test I get:
$ tar tf a8bf8cdd79bec3c4e763d0ddd9ca6b495e380681cfdf0bae9ef5fd1e468229f0/layer.tar
a/
a/b/
a/b/c/
a/b/c/bak
a/b/c/baz
a/b/c/boo
$ tar tf fa2dd663e8549d21e426c58e147464c5cb6ee3cdd199a35057ea92f69bbd4739/layer.tar
a/
a/b/
a/b/c/
a/b/c/.wh.bak
a/b/c/.wh.baz
a/b/c/.wh.boo
a/b/c/foo
I'd favor the one from overlay and other drivers w/o relying on AUFS for generation (while supporting both as you said)
on btrfs:
vbatts@bananaboat ~/x (master) $ cat > Dockerfile
FROM alpine
RUN mkdir -p /a/b/c && touch /a/b/c/baz /a/b/c/boo /a/b/c/bak
RUN rm -rf /a/b/c && mkdir -p /a/b/c && touch /a/b/c/foo
vbatts@bananaboat ~/x (master) $ docker build .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM alpine
---> d7a513a663c1
Step 2 : RUN mkdir -p /a/b/c && touch /a/b/c/baz /a/b/c/boo /a/b/c/bak
---> Running in 73135bca3cbb
---> 7cbd181019b5
Removing intermediate container 73135bca3cbb
Step 3 : RUN rm -rf /a/b/c && mkdir -p /a/b/c && touch /a/b/c/foo
---> Running in a512b0e23c93
---> 15d74ed06d53
Removing intermediate container a512b0e23c93
Successfully built 15d74ed06d53
vbatts@bananaboat ~/x (master) $ docker save 15d74ed06d53 | tar tv
-rw-r--r-- 0/0 1868 2016-07-07 15:21 15d74ed06d537e2498856053338262bb738f28d0ccd5f2cf6fa3e77a1c2fb994.json
drwxr-xr-x 0/0 0 2016-07-07 15:21 34eac2967d619095baa29affc8a5c8ca4bca18647843b8b1c72361f3303ac38b/
-rw-r--r-- 0/0 3 2016-07-07 15:21 34eac2967d619095baa29affc8a5c8ca4bca18647843b8b1c72361f3303ac38b/VERSION
-rw-r--r-- 0/0 388 2016-07-07 15:21 34eac2967d619095baa29affc8a5c8ca4bca18647843b8b1c72361f3303ac38b/json
-rw-r--r-- 0/0 5040640 2016-07-07 15:21 34eac2967d619095baa29affc8a5c8ca4bca18647843b8b1c72361f3303ac38b/layer.tar
drwxr-xr-x 0/0 0 2016-07-07 15:21 717a5b71b79eb8f9eb3be4ce6498b741f0a8e38d1c36f3e9d7ec246de2f6b49c/
-rw-r--r-- 0/0 3 2016-07-07 15:21 717a5b71b79eb8f9eb3be4ce6498b741f0a8e38d1c36f3e9d7ec246de2f6b49c/VERSION
-rw-r--r-- 0/0 1300 2016-07-07 15:21 717a5b71b79eb8f9eb3be4ce6498b741f0a8e38d1c36f3e9d7ec246de2f6b49c/json
-rw-r--r-- 0/0 4608 2016-07-07 15:21 717a5b71b79eb8f9eb3be4ce6498b741f0a8e38d1c36f3e9d7ec246de2f6b49c/layer.tar
drwxr-xr-x 0/0 0 2016-07-07 15:21 83bcf385ed226962fb7132d7c9f915a432db5a8c2a364da438e3e70d6d2fc8fd/
-rw-r--r-- 0/0 3 2016-07-07 15:21 83bcf385ed226962fb7132d7c9f915a432db5a8c2a364da438e3e70d6d2fc8fd/VERSION
-rw-r--r-- 0/0 464 2016-07-07 15:21 83bcf385ed226962fb7132d7c9f915a432db5a8c2a364da438e3e70d6d2fc8fd/json
-rw-r--r-- 0/0 4096 2016-07-07 15:21 83bcf385ed226962fb7132d7c9f915a432db5a8c2a364da438e3e70d6d2fc8fd/layer.tar
-rw-r--r-- 0/0 343 1969-12-31 19:00 manifest.json
vbatts@bananaboat ~/x (master) $ docker save 15d74ed06d53 | tar xO 717a5b71b79eb8f9eb3be4ce6498b741f0a8e38d1c36f3e9d7ec246de2f6b49c/layer.tar | tar tv
drwxr-xr-x 0/0 0 2016-07-07 15:20 a/
drwxr-xr-x 0/0 0 2016-07-07 15:21 a/b/
drwxr-xr-x 0/0 0 2016-07-07 15:21 a/b/c/
---------- 0/0 0 2016-07-07 15:21 a/b/c/.wh.bak
---------- 0/0 0 2016-07-07 15:21 a/b/c/.wh.baz
---------- 0/0 0 2016-07-07 15:21 a/b/c/.wh.boo
-rw-r--r-- 0/0 0 2016-07-07 15:21 a/b/c/foo
vbatts@bananaboat ~/x (master) $ docker save 15d74ed06d53 | tar xO 83bcf385ed226962fb7132d7c9f915a432db5a8c2a364da438e3e70d6d2fc8fd/layer.tar | tar tv
drwxr-xr-x 0/0 0 2016-07-07 15:20 a/
drwxr-xr-x 0/0 0 2016-07-07 15:20 a/b/
drwxr-xr-x 0/0 0 2016-07-07 15:20 a/b/c/
-rw-r--r-- 0/0 0 2016-07-07 15:20 a/b/c/bak
-rw-r--r-- 0/0 0 2016-07-07 15:20 a/b/c/baz
-rw-r--r-- 0/0 0 2016-07-07 15:20 a/b/c/boo
I took a pass at the language in #171.
During the discussion on whiteout files in #141 we hit upon the issue of opaques. From @stevvooe's explanation:
I think the only open item is the handling of opaque directories: https://github.com/docker/docker/blob/22aca92ee3503f811f813be4a1349ad8e67fbbdb/daemon/graphdriver/aufs/aufs.go#L369. From there, it looks like they are actually omitted.
In particular, we have the following case, assuming
/foo/bar
exists and has entries:Based on the specification, we get the following in the top-level tar:
From my understanding of aufs/overlay, this is handled via opq, but these aren't transmitted in layers, currently.