Support Hard Links in Docker Build Context

[hohle]

Is this a BUG REPORT or FEATURE REQUEST?: Feature Request (with patch)

Description

Hard links in the docker build context can be sent to the docker daemon during builds as links within the context tarball. For use cases where there are a significant number of links (for example, objects which are addressable by different names in the filesystem), this can significantly speed up context construction time as well as reduce resulting image size for any commands (COPY, ADD, etc.) which include data linked by multiple directory entries.

CompressedDirectory currently doesn't identify entries which link to the same file so these end up producing two entries with identical content. This is not the case with the default docker client, however, which respects hard links. This causes potentially significant differences in layers created by docker-client vs. those created by the docker CLI.

I've submitted a PR with a patch and test: #1157.

How to reproduce

• create a large file in a build context and link a new entry with the previous
• create a minimal Dockerfile
• build the image

$> cat > Dockerfile
FROM scratch
COPY . /
^D
$> dd if=/dev/random of=orig bs=128m count=8
8+0 records in
8+0 records out
1073741824 bytes transferred in 56.502533 secs (19003428 bytes/sec)
$> ln orig link
# followed by a build using `docker-client`

What do you expect

An image with a single 1.07GB layer with two entries pointing to the same inode.

What happened instead

An image with a single 2.15G layer with two entries pointing to different inodes.

Software:

• docker version: any
• Spotify's docker-client version: all

Full backtrace

NA

[hohle]

Please poke us if you feel you're being neglected, and we'll do our best to get back to you.

Poke.

[hohle]

Poke.

[hohle]

Poke.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.