Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Parallelize OCI layer fetching during OSTree image imports (follow-up to ostree-rs-ext#365)

オープン
  • 何か問題がありますか？
#2,587 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust
領域
backend, performance

調査の方向性

Start by reading the linked ostree-rs-ext#365 issue and tracing the OCI blob fetch and layer import path in bootc, especially the containers-image-proxy-rs integration. Reproduce the provided ostree container image pull benchmark and inspect its debug log; done means bounded concurrent fetching overlaps ordered imports while preserving integrity checks, memory limits, and error handling.

索引モデルが issue の本文から書いたものです。

説明

Parallelize OCI layer fetching during OSTree image imports (follow-up to ostree-rs-ext#365)

Description

When rebasing between Bazzite stable and testing, I've noticed that the OSTree container importer appears to fetch and import OCI layers sequentially, resulting in significantly longer download times compared to Skopeo's concurrent layer downloads.

This appears related to the original issue:

https://github.com/ostreedev/ostree-rs-ext/issues/365

Since ostree-rs-ext has been merged into bootc and the original repository is archived, I'm opening this as a follow-up with reproducible benchmarks and debug logs.

Environment

  • OS: Bazzite, Fedora 44

  • rpm-ostree: 2026.3-2.fc44

  • OSTree: 2026.4-1.fc44

  • bootc: 1.16.13-1.fc44

  • Skopeo: 1.22.3

  • Image: ghcr.io/ublue-os/bazzite:stable

  • Image layers: 128

  • Reported download size: 5.1 GB

  • Internet connection: 2 Gbps downstream

Benchmark results

I tested the same Bazzite image using three different download methods.

Method | Real time | User CPU | System CPU -- | -- | -- | -- Skopeo (1 concurrent layer) | 57.673s | 19.708s | 11.826s Skopeo (8 concurrent layers) | 38.486s | 26.165s | 21.951s OSTree container image pull | 206.820s | 1.745s | 6.092s

Skopeo with eight concurrent layers completed approximately 33% faster than Skopeo with one.

The OSTree pull took approximately 5.37 times as long as the eight-layer Skopeo test.

These are single-run measurements, not repeated statistical benchmarks. The Skopeo dir: transport and OSTree repository import also perform different amounts of work, so the entire difference cannot be attributed to download concurrency alone.

Reproduction

Skopeo, single concurrent layer:

mkdir -p /var/tmp/bazzite-skopeo-serial

time skopeo copy 

--image-parallel-copies 1 

docker://ghcr.io/ublue-os/bazzite:stable 

dir:/var/tmp/bazzite-skopeo-serial

Skopeo, eight concurrent layers:

mkdir -p /var/tmp/bazzite-skopeo-parallel


time skopeo copy 

--image-parallel-copies 8 

docker://ghcr.io/ublue-os/bazzite:stable 

dir:/var/tmp/bazzite-skopeo-parallel

OSTree container image pull using a separate, clean repository:

sudo mkdir -p /var/tmp/bazzite-pull-test


sudo ostree 

--repo=/var/tmp/bazzite-pull-test 

init --mode=bare-user


time sudo ostree container image pull 

/var/tmp/bazzite-pull-test 

ostree-unverified-registry:ghcr.io/ublue-os/bazzite:stable

The standalone OSTree test used an unverified registry reference only to isolate the import behavior without configuring image-signature verification.

Debug findings

I repeated the OSTree pull with:

sudo env 

RUST_LOG=ostree_ext=trace,containers_image_proxy=debug 

ostree container image pull 

/var/tmp/bazzite-pull-test 

ostree-unverified-registry:ghcr.io/ublue-os/bazzite:stable 

2>&1 | tee /var/tmp/ostree-pull-debug.log

The log repeatedly shows the following sequence:

DEBUG fetching sha256:<digest A>

DEBUG get_blob: fetching blob

DEBUG finish_pipe: closing pipe

DEBUG Imported ... content objects

DEBUG Wrote ostree/container/blob/...


DEBUG fetching sha256:<digest B>

DEBUG get_blob: fetching blob

DEBUG finish_pipe: closing pipe

DEBUG Imported ... content objects

DEBUG Wrote ostree/container/blob/...

The next layer's fetch is not logged until the preceding layer's import and reference write have completed.

This is consistent with sequential fetch/import processing, although the log alone does not conclusively rule out internal prefetching.

Network monitoring also showed fewer Skopeo TCP connections during the OSTree pull than during a direct Skopeo copy with eight concurrent transfers.

Proposed improvement

Would it be possible to decouple OCI blob fetching from sequential OSTree layer importing?

For example:

  1. Fetch a bounded number of OCI blobs concurrently (perhaps 2–4 initially).

  2. Buffer or stage completed downloads as needed.

  3. Continue importing layers in their required order.

  4. Overlap network fetching with the import of previously downloaded layers.

  5. Preserve integrity verification, memory limits, and proper error handling.

An optional configuration to control download concurrency could also be useful, particularly on faster connections.

The original issue mentioned concurrent fetching/unpacking and possible concurrency changes to containers-image-proxy-rs:

https://github.com/ostreedev/ostree-rs-ext/issues/365

I'd be interested to know whether that work is still planned, whether any architectural limitations remain, or whether the current bootc implementation has an alternative parallel download path.

I'm happy to provide additional logs, repeat benchmarks, or help test potential changes.

主要言語
Rust
スター
2.3k
フォーク
230
平均マージ
2日 19時間
マージ済み PR（30日）
42

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

bootc-dev/bootc のほかの issue

bootc-dev/bootc の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。