标题说明了一切。我有几个卷设置为只读 (:ro) 但想测试 :cached 和 :delegated 以帮助提高文件 i/o 性能，但不知道如何在 compose 中设置它文件。
哦，我已经测试过了：
volumes:
- external:internal:cached
【问题讨论】：
:cached）并在osx 上得到Mounts denied: 9p: Stack overflow 错误。
标签： docker docker-compose
说明：在docker上使用volumes配置的目的是为了在宿主机和docker容器之间共享数据，保证两者之间的数据一致性（A(host/container) 在 B(host/container) 中表示，反之亦然)。安装的卷是容器的“一部分”并且是相关的。常见的用法是将共享数据备份存储在容器和机器的文件系统中。如果容器被移除，卷仍然存在并且独立于容器状态，它将被重用并从最后一个持久状态加载。
TLDR：
cached：当主机执行更改时，容器处于只读模式。delegated：当docker容器执行更改时，主机处于读取状态
唯一模式。default：当容器和主机都主动和
持续对数据进行更改。来自文档：
Mac 使用
osxfs将从 macOS 共享的目录和文件传播到 Linux VM。这种传播使这些目录和文件可用于在 Docker Desktop for Mac 上运行的 Docker 容器。 **默认情况下，这些共享是完全一致的，这意味着每次在 macOS 主机上或通过容器中的挂载发生写入时，更改都会刷新到磁盘，以便共享中的所有参与者都具有完全一致的视图.在某些情况下，完全一致性会严重影响性能。** Docker 17.05 及更高版本引入了调整一致性的选项 在每个装载、每个容器的基础上进行设置。以下选项是 可用：
consistency选项（如果存在）可能是consistent、delegated或cached之一。此设置仅适用于 Docker Desktop for Mac，在所有其他平台上均被忽略。
Docker 卷标志是：
consistent 或 default：具有完全一致性的默认设置，如上所述。delegated：容器运行时的挂载视图是权威的。在容器中所做的更新在主机上可见之前可能会有延迟。
什么时候使用？例如，当容器不断更改数据并希望在主机上备份此数据时使用它，这是主机角度的只读操作，因此将委派正确的选择。cached：macOS 主机对挂载的看法是权威的。在主机上进行的更新在容器中可见之前可能会有延迟。 何时使用？例如，当您的主机不断更改容器服务读取并使用它的数据时（如配置/源代码/来自服务器的渲染数据等...）用法：
- <my-first-host-volume>:<first-container-volume-path>:delegated
- <my-second-host-volume>:<second-container-volume-path>:cached
示例：
version: '3.4'
services:
jenkins:
image: jenkins/jenkins:lts
environment:
- JENKINS_HOME=/var/jenkins_home
container_name: jenkins
volumes:
- '~/jenkins/:/var/jenkins_home:delegated'
- '~/environment_keys:/var/data:cached'
ports:
- 0.0.0.0:8080:8080
expose:
- 5000
restart: unless-stopped
【讨论】：
consistent、default、delegated 和 cached 这样的 docker 卷标志
就我而言，我想要一个readonly (:ro) 卷，它也是:cached 或:delegated。为此，您只需使用以下语法：
volumes:
- /external/folder:/internal/folder:ro,cached
【讨论】：
cached 与ro 结合使用？我从 docker 文档中的理解是，如果您不需要从容器到主机的额外写入一致性保证，delegated 会更快，并且使用 ro 您永远不会再写出来？
webpack-dev-server 拾取。我想使用ro，因为容器永远不需要写入这个文件夹，而cached，因为我不介意偶尔保存会导致延迟。但是，如果由于发生同步而导致更频繁的读取被延迟，我会介意。 “因此，cached 通常会提高读取繁重工作负载的性能，但代价是主机和容器之间存在一些暂时的不一致。”这就是为什么我认为它是最好的，但文档并不完全清楚。
delegated: 容器运行时的挂载视图是权威的。在容器中所做的更新在主机上可见之前可能会有延迟。”并且“……容器的写入可能不会立即反映在主机上……但是，通过放弃一致性，委托挂载提供的性能明显优于其他配置。”
我没有运行足够新的（边缘通道）版本的 Docker，因此命令不起作用。升级后，一切正常。
【讨论】：
cached 添加到 docker 的版本是什么？
此答案与问题没有直接关系，但目的相同。
docker-sync 项目旨在解决 macOS 和 Windows 上的慢同步问题。我已经为一些 Ruby on Rails 应用程序设置了它，结果令人惊讶。对于其他类型的项目，结果应该相同。
这是我的模板 dockerfile-compose
version: '3.4'
volumes:
app-code:
external: true
services:
backend:
volumes:
- app-code/:/app:rw
还有 docker-sync 文件
version: 2
syncs:
app-code:
src: './'
sync_strategy: 'native_osx'
sync_excludes:
- '.git'
- 'coverage'
- .gitignore'
watch_excludes:
- '.*/.git'
- '.gitignore'
- 'log'
- 'docker-*.yml'
然后您可以docker-sync start 或按照文档使用 docker-sync 代替 docker-compose 在需要时自动启动/停止同步。
主要缺点之一是依赖于您必须在操作系统上安装的 docker-sync gem，但是一旦设置好它就可以很好地工作。
【讨论】：
我觉得这个帖子需要更新以更好地反映当前情况。
自从 Docker for Mac 开始包含 gRPC-FUSE 以来，这些标志已从 Docker 文档中删除，因为它们不再需要。从 docker-compose.yml 文件中删除它们是安全的。
https://github.com/docker/for-mac/issues/5402
您可以看到在 Docker Desktop 中默认选择了 gRPC-FUSE。转到“设置”>“常规”选项卡。
【讨论】：