Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#651 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker
Domain
infrastructure, operating-systems

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
PowerShell
Stars
551
Forks
76
No merged PRs in 30d

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/Windows-Containers

All issues in microsoft/Windows-Containers

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.