为什么Docker vfs存储后端不适合生产？
Docker vfs存储后端在几个地方被提到，并不是产品后端（例如，参见Michael Crosby的Docker GitHub 问题评论 ）。 是什么让它不适合生产？
Project Atomic 对存储后端的描述说：
vfs后端是一个非常简单的后备，没有写时复制的支持。 每一层只是一个单独的目录。 基于另一个图层创build一个新的图层是通过将基础图层的深层复制到一个新的目录中完成的。
由于这个后端没有共享磁盘空间的使用，而且由于创build一个新层是一个缓慢的操作，所以这不是一个非常实用的后端。 但是，它仍然有其用途，例如validation其他后端，或者如果您需要一个超级健壮（如果缓慢）的后端，无处不在。
根据这个描述，这听起来像唯一的缺点是可能会使用更多的磁盘空间，创build图层可能会更慢。 但在运行时访问文件时没有提到缺点，甚至被描述为“健壮”。 磁盘空间问题本身似乎不是生产使用的阻碍者。
实际上，您可以在生产环境中使用vfs驱动程序，但请注意，由于它是“常规”副本，因此您不会受益于devicemapper或btrfs可以提供的function，而只依赖于基础文件系统。
运行时间的缺点是run速度要慢很多。 一旦开始，如果你有相同的基础文件系统，它将是同样的事情。
总之，我会build议反对，因为：
- 它已经被首先用于testing，然后用于卷。 永远不要用于运行时
- 它依赖于底层的文件系统，所以你可以减lessDocker对你的文件的控制。 它可能（或不可能）导致未来升级的问题。 Docker的目的是抽象主机，所以你最好把这种事情委托给Docker。
- 这需要大量的磁盘空间
- 运行或提交需要很长时间