什么是/ var/lib/docker/graph/<image GUID>

Question

中的tar-data.json.gz我使用的是Docker 1.8.3。 /var/lib/docker/repositories-aufs存储与# docker images的输出匹配的本地图像信息。 /var/lib/docker/graph/<image GUID>维护每个图像的元数据等。

json保存关于图像的元数据。

layersize指示图层的大小。

什么是tar-data.json.gz和v1Compatibility？已被PR 14067在搬运工1.8推出
这似乎是：

# ll /var/lib/docker/graph/ca0ef69 
drwx------ 2 root root 4096 10月 29 12:08 ./ 
drwx------ 150 root root 20480 11月 1 12:29 ../ 
-rw------- 1 root root 1384 10月 29 12:06 json 
-rw------- 1 root root  1 10月 29 12:06 layersize 
-rw------- 1 root root 82 10月 29 12:06 tar-data.json.gz 
-rw------- 1 root root 1384 10月 29 12:08 v1Compatibility 

Answer 1

tar-data.json.gz存储图像层。

该拉取请求引入了一个用于内联反汇编TAR存档的库（vbatts/tar-split）。
反汇编不会执行任何提取操作，但会保留存档中标题和填充的原始字节，并推迟提取。这种验证和提取仍然是一个锁步骤过程。

对于码头牵引，码头装载或码头工提交此功能后，将为图像层存储新的状态文件（例如/var/lib/docker/graph/<ID>/tar-data.json.gz）。

对于没有这个新状态文件的现有映像，由docker save或docker push生成的tar归档将像原来一样回退到传统的graphdriver.Diff。

此功能的好处是，而不是希望生成的graph.TarLayer是确定性的，tar归档将从原始归档的原始字节重新组合。

目前存在的问题是，从像Docker中心这样的回购库中提取图像，然后推送到本地注册表可能会有一个新的摘要。

---

v1compatibility在泊坞窗1.3（commit 15d5c7f）被引入，但仅用于与manifest.go

// History stores unstructured v1 compatibility information 
type History struct { 
    // V1Compatibility is the raw v1 compatibility information 
    V1Compatibility string `json:"v1Compatibility"` 
} 

而且真的泊坞窗1.8（commit 745820f）在泊坞窗1.9（commit 504e67b）用于graph/graph.go，其中与清单中的图像关联的v1Compatibility JSON数据关联 存储到磁盘。 然后graph/pull_v2.go，当试图重新使用标签时，可以检查其兼容性。
你可以看到它在graph/pull_v2_test.go中使用。