Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers

未关闭
  • 哪里不对？
#651 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
docker
领域
infrastructure, operating-systems

调研方向

No files, tests, or implementation entry points are identified. Start by locating the CimFS layer-composition and Windows container storage code, then review how writable and read-only layers are mounted; done requires measurable copy-up, shared-page, and cold/warm container-start benchmarks against Linux overlayfs.

由索引模型根据 Issue 内容生成。

描述

enhancement triage

Is your feature request related to a problem? Please describe.

Windows container image layers are still fundamentally VHD/reparse-point-based even where CimFS is used for the read-only layer store, whereas Linux containers get true union-mount semantics from overlayfs: cheap copy-up on first write, shared page cache across containers referencing the same read-only layer, and near-instant layer composition at container start. In practice this shows up as:

  1. Slower container create/start times on Windows nodes relative to Linux nodes for images with deep layer stacks, because layer composition still involves more filesystem-level setup work than a Linux overlay mount.
  2. Weaker read-only layer page-cache sharing across containers on the same host — multiple containers built from the same base image don't get the same "one copy of the base image's pages in memory, shared by all instances" behavior Linux gets from overlayfs + the page cache, which hurts density on nodes running many containers from a common base.
  3. Copy-on-write semantics on first write to a layered file are less predictable/performant than overlayfs's copy-up, which affects any workload that writes to files inherited from a lower layer (package managers, log rotation into inherited directories, etc.).

Describe the solution you'd like

  • Extend CimFS (or a successor) to provide true union-mount semantics for the full container layer stack, not just the read-only base — i.e., an overlay driver where upper (writable) and lower (read-only, CimFS-backed) layers are composed at the filesystem level with overlayfs-equivalent copy-up cost, rather than today's per-layer VHD/reparse composition.
  • Guarantee that read-only layer pages are shared in memory across all containers on a host referencing the same layer, verifiable via a documented/measurable metric (e.g., working-set pages attributable to a shared layer vs. per-container private pages), so this is testable rather than an implementation detail nobody can confirm.
  • Publish container create/start latency benchmarks (cold and warm cache) for a representative multi-layer image (e.g., a typical .NET or Node base + app layers) versus an equivalent Linux overlayfs container, so parity progress is measurable release over release rather than anecdotal.

Describe alternatives you've considered

  • Silo/container pre-warming (create idle, attach on demand): mitigates start latency for high-churn workloads today, but is a workaround at the orchestration layer, not a fix to the underlying layer-composition cost — and it doesn't help the memory-sharing/density problem at all.
  • Sticking with current CimFS-for-read-only-layers-only: is already an improvement over the older VHD-only model, but doesn't close the gap on writable-layer copy-up cost or on measurable page-sharing guarantees, which is the part of this ticket that most affects density.
  • Recommending larger, less-layered images to reduce composition cost: works around the problem for individual teams but doesn't scale as general guidance and goes against standard container image-layering best practices that exist specifically to maximize layer reuse.

Additional context

Filed as a follow-up to #[syscall/capability filtering ticket https://github.com/microsoft/Windows-Containers/issues/649] and #[PID namespace ticket https://github.com/microsoft/Windows-Containers/issues/650], same feature/performance parity-with-Linux-containers effort. This ticket is scoped to layer composition and memory-sharing performance; the separate, harder problem of host/container kernel-version lockstep (which also affects image portability, not performance) is intentionally out of scope here.

主要语言
PowerShell
星标
556
派生
75
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/Windows-Containers 的其他 Issue

查看 microsoft/Windows-Containers 的全部 Issue

相似的 Issue

更多 DevOps Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。