kvcache-ai/AgentENV

Fork 0

mirror of https://github.com/kvcache-ai/AgentENV.git synced 2026-11-05 01:17:36 +00:00

[GH-ISSUE #140] refactor(ublk): remove the legacy CoW target #48

New issue

Closed

opened 2026-10-29 14:18:47 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-29 14:18:47 +00:00

Owner

Originally created by @yingdi-shan on GitHub (Aug 7, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/140

Affected component

ublk / ublk-daemon

Problem statement

AgentENV's production block-device path uses OverlayBD, but uvm-ublk still maintains the separate BasicCowTarget implementation.

The CoW target has no production caller in AgentENV. However, it remains exposed through the Rust API, standalone CLI, daemon protocol, configuration, tests, and documentation. This creates a second concurrency-sensitive I/O path that must be maintained despite no longer supporting current sandbox, snapshot, or resume workflows.

The configuration is also misleading: ublk.device_type = "cow" is accepted even though current sandbox creation and snapshot restoration depend on OverlayBD.

Use case

Maintainers changing ublk queues, I/O buffers, daemon lifecycle handling, or snapshot behavior currently need to account for an unused target and its protocol branches. Every build and release also continues to expose and test this unsupported path.

Operators need the configuration and CLI to reflect the storage backend AgentENV actually supports.

Current behavior and workarounds

BasicCowTarget is currently exposed through:

storage/ublk/src/impls/cow.rs
The uvm-ublk create cow CLI subcommand
The daemon's CreateCow request
UblkDaemonClient::create_cow
ManagedDevice::Cow
UblkBackend::Cow and UblkConfig::cow()
ublk.device_type = "cow"
CoW-specific unit, integration, protocol, and daemon tests

AgentENV production code does not call create_cow; fresh sandbox and snapshot paths create OverlayBD devices.

There is no useful workaround other than continuing to maintain these dormant interfaces.

Desired behavior

Given a supported AgentENV configuration, when ublk is enabled, then OverlayBD is the only available target.
Given ublk.device_type = "cow", when AgentENV starts, then it fails with an actionable message directing the operator to OverlayBD.
Given the standalone uvm-ublk CLI, when listing target types, then no cow subcommand is exposed.
Given the daemon protocol, when compiling clients and servers, then no CreateCow request or CoW-managed device exists.
BasicCowTarget, BasicCowConfig, UblkBackend::Cow, and their tests are removed.
Relevant formatting, lint, and ublk test suites pass.

Proposed approach

Delete the BasicCowTarget implementation and its tests.
Remove its exports from uvm-ublk.
Remove the standalone CLI's cow target and now-unused --zero-copy option.
Remove CreateCow from the daemon protocol.
Remove UblkDaemonClient::create_cow, the server handler, and ManagedDevice::Cow.
Remove associated protocol, client, server, and integration tests.
Remove UblkBackend::Cow and UblkConfig::cow().
Simplify matches that currently retain CoW branches.
Retain device_type as an OverlayBD-only compatibility setting for now, but reject cow explicitly.
Remove dependencies used only by the target, including futures-util, dashmap, and the rand dev dependency when no other consumer remains.
Update configuration, architecture, testing, and contributor documentation.

Validation should include:

cargo fmt --all --check
cargo clippy -p uvm-ublk -p uvm-ublk-daemon --all-targets -- -D warnings
cargo test -p uvm-ublk -p uvm-ublk-daemon

Compatibility and operational impact

API/config changes:

The BasicCowTarget Rust API, uvm-ublk create cow command, and internal CreateCow daemon request are removed. Explicit device_type = "cow" configurations are rejected.

Snapshot or storage format changes:

No OverlayBD or snapshot artifact formats change. Persisted sandbox state containing UblkBackend::Cow cannot be resumed and should produce a clear migration error.

New host/runtime requirements:

None.

Pre-submission checklist

I searched existing issues and discussions and did not find a duplicate.
I described a concrete problem and use case, not only a proposed technology.
I understand that acceptance of the problem does not imply approval of a particular implementation.

Originally created by @yingdi-shan on GitHub (Aug 7, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/140 ### Affected component ublk / ublk-daemon ### Problem statement AgentENV's production block-device path uses OverlayBD, but `uvm-ublk` still maintains the separate `BasicCowTarget` implementation. The CoW target has no production caller in AgentENV. However, it remains exposed through the Rust API, standalone CLI, daemon protocol, configuration, tests, and documentation. This creates a second concurrency-sensitive I/O path that must be maintained despite no longer supporting current sandbox, snapshot, or resume workflows. The configuration is also misleading: `ublk.device_type = "cow"` is accepted even though current sandbox creation and snapshot restoration depend on OverlayBD. ### Use case Maintainers changing ublk queues, I/O buffers, daemon lifecycle handling, or snapshot behavior currently need to account for an unused target and its protocol branches. Every build and release also continues to expose and test this unsupported path. Operators need the configuration and CLI to reflect the storage backend AgentENV actually supports. ### Current behavior and workarounds `BasicCowTarget` is currently exposed through: - `storage/ublk/src/impls/cow.rs` - The `uvm-ublk create cow` CLI subcommand - The daemon's `CreateCow` request - `UblkDaemonClient::create_cow` - `ManagedDevice::Cow` - `UblkBackend::Cow` and `UblkConfig::cow()` - `ublk.device_type = "cow"` - CoW-specific unit, integration, protocol, and daemon tests AgentENV production code does not call `create_cow`; fresh sandbox and snapshot paths create OverlayBD devices. There is no useful workaround other than continuing to maintain these dormant interfaces. ### Desired behavior - Given a supported AgentENV configuration, when ublk is enabled, then OverlayBD is the only available target. - Given `ublk.device_type = "cow"`, when AgentENV starts, then it fails with an actionable message directing the operator to OverlayBD. - Given the standalone `uvm-ublk` CLI, when listing target types, then no `cow` subcommand is exposed. - Given the daemon protocol, when compiling clients and servers, then no `CreateCow` request or CoW-managed device exists. - `BasicCowTarget`, `BasicCowConfig`, `UblkBackend::Cow`, and their tests are removed. - Relevant formatting, lint, and ublk test suites pass. ### Proposed approach - Delete the `BasicCowTarget` implementation and its tests. - Remove its exports from `uvm-ublk`. - Remove the standalone CLI's `cow` target and now-unused `--zero-copy` option. - Remove `CreateCow` from the daemon protocol. - Remove `UblkDaemonClient::create_cow`, the server handler, and `ManagedDevice::Cow`. - Remove associated protocol, client, server, and integration tests. - Remove `UblkBackend::Cow` and `UblkConfig::cow()`. - Simplify matches that currently retain CoW branches. - Retain `device_type` as an OverlayBD-only compatibility setting for now, but reject `cow` explicitly. - Remove dependencies used only by the target, including `futures-util`, `dashmap`, and the `rand` dev dependency when no other consumer remains. - Update configuration, architecture, testing, and contributor documentation. Validation should include: ```shell cargo fmt --all --check cargo clippy -p uvm-ublk -p uvm-ublk-daemon --all-targets -- -D warnings cargo test -p uvm-ublk -p uvm-ublk-daemon ``` ### Compatibility and operational impact API/config changes: The `BasicCowTarget` Rust API, `uvm-ublk create cow` command, and internal `CreateCow` daemon request are removed. Explicit `device_type = "cow"` configurations are rejected. Snapshot or storage format changes: No OverlayBD or snapshot artifact formats change. Persisted sandbox state containing `UblkBackend::Cow` cannot be resumed and should produce a clear migration error. New host/runtime requirements: None. ### Pre-submission checklist - [x] I searched existing issues and discussions and did not find a duplicate. - [x] I described a concrete problem and use case, not only a proposed technology. - [x] I understand that acceptance of the problem does not imply approval of a particular implementation.

bsakaguchi

2026-10-29 14:18:47 +00:00

closed this issue
added the
enhancement
label

bsakaguchi commented

2026-10-29 14:18:48 +00:00

Author

Owner

@xiecl666 commented on GitHub (Aug 8, 2026):

I'd like to take this one.

@xiecl666 commented on GitHub (Aug 8, 2026): I'd like to take this one.

bsakaguchi commented

2026-10-29 14:18:49 +00:00

Author

Owner

@yingdi-shan commented on GitHub (Aug 8, 2026):

I'd like to take this one.

Thanks, but we have implemented it in PR #142.

@yingdi-shan commented on GitHub (Aug 8, 2026): > I'd like to take this one. Thanks, but we have implemented it in PR #142.

bsakaguchi referenced this issue

2026-10-29 14:20:07 +00:00

[PR #48] [MERGED] feat(sandbox): add Firecracker disk I/O rate limiting (bandwidth + IOPS) #138