fix(ckpt): open loop device in direct-io mode - #2523
Merged
Conversation
|
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1dafa3672d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
yummypeng
reviewed
Aug 14, 2026
qiwu575757
force-pushed
the
fix/ckpt/loop-direct-io
branch
from
August 14, 2026 08:30
1dafa36 to
3025db0
Compare
yummypeng
reviewed
Aug 14, 2026
The btrfs-loop backend attached its image with `losetup --find --show`,
which leaves the loop device in buffered mode (DIO=0). Any O_DIRECT
issued by btrfs on top of the loop is then silently downgraded to
buffered IO against the host image file: data crosses two page caches
(the loop filesystem's and the host ext4's) and every request is
serialized through the single loop kernel thread. The loop backend
therefore had no end-to-end O_DIRECT at all, and its data path became
the bottleneck under concurrent IO.
Measured on 5.10.134-19.6.3, ws-ckpt 0.4.2, 40 GiB image on a 100 GiB
ESSD PL1 host, comparing the same workloads before and after:
checkpoint under fio pressure 305.10 ms -> 62.55 ms (5.3x -> 1.08x
of btrfs-base; p50 42 vs 41 ms and
p99 237 vs 237 ms now match base)
checkpoint under dual pressure 327.98 ms -> 139.75 ms
10h soak throughput 705 -> 1355 cycles/h
soak checkpoint / rollback 291.07 -> 120.58 ms / 332.13 -> 107.84 ms
Add `--direct-io=on` to all four `losetup --find --show` call sites, so
bootstrap, post-rename remount, legacy rollback reattach and image-grow
reattach all open the device in direct mode. All direct-IO handling is
best-effort: when the kernel or tooling rejects it, the daemon logs a
warning and keeps running in buffered mode exactly as before, never
blocking bootstrap. Loops already attached in buffered mode are not
switched to direct-IO on daemon restart, to keep overall system
performance stable; they converge on the next reattach or host reboot.
Validated on the same host with the full ws-ckpt suite after the change:
421075 operations, zero non-zero exits and zero SHA256 integrity
mismatches, covering daemon kill -9 recovery, host filesystem
exhaustion, image size cap, 4-process and 4-workspace concurrency, a
10h soak and 32k snapshot accumulation.
Assisted-by: Qoder
Signed-off-by: Qi Wu <shijing.wq@alibaba-inc.com>
qiwu575757
force-pushed
the
fix/ckpt/loop-direct-io
branch
from
August 17, 2026 03:06
3025db0 to
83569e0
Compare
Collaborator
|
@qiwu575757 这里有一个 pending task |
Collaborator
Author
我已经点进去选择同意了，但是流程上好像还是卡在上面这一步 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The btrfs-loop backend attached its image with
losetup --find --show, which leaves the loop device in buffered mode (DIO=0). Any O_DIRECT issued by btrfs on top of the loop is then silently downgraded to buffered IO against the host image file: data crosses two page caches (the loop filesystem's and the host ext4's) and every request is serialized through the single loop kernel thread. The loop backend therefore had no end-to-end O_DIRECT at all, and its data path became the bottleneck under concurrent IO.Measured on 5.10.134-19.6.3, ws-ckpt 0.4.2, 40 GiB image on a 100 GiB ESSD PL1 host, comparing the same workloads before and after:
checkpoint under fio pressure 305.10 ms -> 62.55 ms (5.3x -> 1.08x
of btrfs-base; p50 42 vs 41 ms and
p99 237 vs 237 ms now match base)
checkpoint under dual pressure 327.98 ms -> 139.75 ms
10h soak throughput 705 -> 1355 cycles/h
soak checkpoint / rollback 291.07 -> 120.58 ms / 332.13 -> 107.84 ms
Add
--direct-io=onto all fourlosetup --find --showcall sites, so bootstrap, post-rename remount, legacy rollback reattach and image-grow reattach all open the device in direct mode. No plain attach remains in this file, so a fallback path cannot silently reintroduce buffered mode.Validated on the same host with the full ws-ckpt suite after the change: 421075 operations, zero non-zero exits and zero SHA256 integrity mismatches, covering daemon kill -9 recovery, host filesystem exhaustion, image size cap, 4-process and 4-workspace concurrency, a 10h soak and 32k snapshot accumulation.