Blockdev changes #3937
Blockdev changes #3937
Conversation
WalkthroughReplaces dbus/dbus-tree with optional zbus/zvariant and adds a zbus-based D-Bus surface: base constants, manager/pool/filesystem/blockdev R0–R9 interfaces, shared helpers/macros, UdevHandler, registration orchestration, IPC rewiring, Name-based filesystem API changes, and many property/method implementations. (44 words) Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Runner as run.rs
participant DBusInit as create_dbus_handler
participant Conn as zbus::Connection
participant Manager as Manager registry
participant Udev as UdevHandler
participant Engine as Engine
Runner->>DBusInit: create_dbus_handler(engine, udev_receiver)
DBusInit->>Conn: open system connection (STRATIS_BASE_SERVICE)
DBusInit->>Manager: register_manager(connection, engine, manager, counter)
Manager->>Manager: register ManagerR0..R9 at STRATIS_BASE_PATH
DBusInit->>Udev: construct UdevHandler(connection, engine, manager, receiver, counter)
DBusInit-->>Runner: return (connection, udev_handler, manager)
Runner->>Udev: spawn process_udev_events
Udev->>Engine: engine.handle_events(events)
Engine-->>Udev: pool_infos
Udev->>Manager: register_pool(pool_uuid)
Manager->>Conn: register pool, filesystem, blockdev objects (sequential register calls)
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes
Suggested labels
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/engine/strat_engine/pool/v2.rs (1)
751-800: The review comment is accurate—remove the unused lifetime parameter fromcreate_filesystemsin v2.rsThe Pool trait in
src/engine/engine.rs(lines 162–167) definescreate_filesystemswith no lifetime parameter, but the implementation insrc/engine/strat_engine/pool/v2.rs(line 751) declaresfn create_filesystems<'a>(...), which causes a trait signature mismatch. The lifetime is not used in the method body and would be a compile-time error. All other implementations (v1, dispatch, sim_engine) correctly omit the lifetime.The fix is correct as stated in the review: remove the
<'a>generic parameter from the impl method signature at line 751.
🧹 Nitpick comments (6)
src/stratis/ipc_support/jsonrpc_support.rs (1)
21-35: try_recv()-based drain correctly batches events; optional consideration on batch sizeThe new pattern of awaiting a single
recv().awaitand then draining withwhile let Ok(event) = recv.try_recv()correctly:
- Handles the channel-closed case via the outer
recv().awaitreturningNone.- Batches all currently queued events into one
Vecfor a singleengine.handle_events(events).awaitcall.Semantics look sound. If udev bursts can be very large, you might optionally consider capping the number of
try_recv()iterations per loop to avoid extremely large batches or long single-task runs, but that’s a design/perf choice, not a correctness issue.src/dbus/macros.rs (1)
5-12: handle_action! macro is correct; consider usingDebugfor broader applicabilityMacro behavior (single evaluation, returning original
Result) looks good. Thelog::info!("{}", a)line requires all Ok payload types to implementDisplay; for a general-purpose helper that will wrap various engine actions, using"{:?}"and aDebugbound is usually less constraining and avoids needing to implementDisplayon every action/result type.src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-20:new_physical_size_propmatches existing patterns; clarify theset_user_info_propstub’s intentThe
new_physical_size_propimplementation aligns with the usual(bool, String)property convention and looks correct.
set_user_info_propis currently a no-op stub marked FIXME and allowed as dead code. If this setter is not meant to be wired into any D-Bus property yet, that’s fine; otherwise, consider either removing it until needed or implementing at least a minimal behavior (e.g., returning an error) so that accidental wiring doesn’t silently ignore updates.src/dbus/pool/shared.rs (1)
11-39: Pool helpers look correct; considerFnOnceand clarifyingtry_pool_propsemanticsImplementation and error mapping are fine. Two minor ergonomic points:
- Both helpers only invoke the closure once, so
f: impl FnOnce(...) -> Rwould be strictly more flexible thanFn(...) -> Rfor callers that move captured values.pool_propandtry_pool_propcurrently behave identically; if this mirrors an older API, consider adding a brief comment about why both exist now, or givetry_pool_propdistinct semantics so the naming conveys a real difference.src/dbus/blockdev/shared.rs (1)
45-47: Clarify the not-found error message.This branch still reports “filesystem” when the helper is resolving block devices, which leaks a misleading failure over D-Bus. Please update the wording.
- .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;src/engine/types/mod.rs (1)
58-68: Align trait derives for UUID newtypes acrossdbus_enabledand non‑DBus buildsRight now the uuid! macro derives
Ord,PartialOrd, andDefaultonly whendbus_enabledis set, while the non‑DBus branch omits them. That makes the public capabilities ofDevUuid/FilesystemUuid/PoolUuiddepend on the feature flag, which can be surprising and complicate shared generic code.Consider deriving the same trait set in both branches (with
Typegated only behinddbus_enabled) to keep these wrappers consistent across builds. For example:- #[cfg(not(feature = "dbus_enabled"))] - #[derive(Copy, Clone, Debug, Hash, Eq, PartialEq, Deserialize, Serialize)] - $vis struct $ident(pub uuid::Uuid); + #[cfg(not(feature = "dbus_enabled"))] + #[derive( + Copy, + Clone, + Debug, + Hash, + Eq, + PartialEq, + Ord, + PartialOrd, + Default, + Deserialize, + Serialize, + )] + $vis struct $ident(pub uuid::Uuid);This keeps behavior uniform while still only enabling zvariant
TypeandFrom<$ident> for Valuewhen DBus support is compiled in.Also applies to: 99-104
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (61)
Cargo.toml(2 hunks)src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/consts.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)src/dbus/macros.rs(1 hunks)src/dbus/manager/manager_3_0/methods.rs(1 hunks)src/dbus/manager/manager_3_0/mod.rs(1 hunks)src/dbus/manager/manager_3_0/props.rs(1 hunks)src/dbus/manager/manager_3_1/mod.rs(1 hunks)src/dbus/manager/manager_3_2/methods.rs(1 hunks)src/dbus/manager/manager_3_2/mod.rs(1 hunks)src/dbus/manager/manager_3_2/props.rs(1 hunks)src/dbus/manager/manager_3_8/methods.rs(1 hunks)src/dbus/manager/manager_3_8/mod.rs(1 hunks)src/dbus/manager/manager_3_9/mod.rs(1 hunks)src/dbus/manager/mod.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/dbus/pool/pool_3_0/mod.rs(1 hunks)src/dbus/pool/pool_3_0/props.rs(1 hunks)src/dbus/pool/pool_3_6/methods.rs(1 hunks)src/dbus/pool/pool_3_6/mod.rs(1 hunks)src/dbus/pool/pool_3_9/mod.rs(1 hunks)src/dbus/pool/shared.rs(1 hunks)src/dbus/types.rs(1 hunks)src/dbus/udev.rs(1 hunks)src/dbus/util.rs(1 hunks)src/engine/engine.rs(1 hunks)src/engine/mod.rs(1 hunks)src/engine/sim_engine/pool.rs(5 hunks)src/engine/strat_engine/pool/dispatch.rs(1 hunks)src/engine/strat_engine/pool/v1.rs(2 hunks)src/engine/strat_engine/pool/v2.rs(2 hunks)src/engine/types/actions.rs(2 hunks)src/engine/types/keys.rs(4 hunks)src/engine/types/mod.rs(4 hunks)src/lib.rs(1 hunks)src/stratis/dm.rs(4 hunks)src/stratis/errors.rs(3 hunks)src/stratis/ipc_support/dbus_support.rs(1 hunks)src/stratis/ipc_support/jsonrpc_support.rs(2 hunks)src/stratis/run.rs(2 hunks)src/stratis/timer.rs(4 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/manager/manager_3_8/mod.rssrc/dbus/manager/manager_3_0/props.rssrc/dbus/pool/pool_3_0/mod.rssrc/dbus/pool/pool_3_0/props.rssrc/dbus/blockdev/shared.rssrc/dbus/manager/manager_3_8/methods.rssrc/engine/engine.rssrc/dbus/pool/shared.rssrc/dbus/pool/pool_3_6/mod.rssrc/dbus/manager/manager_3_2/methods.rssrc/engine/strat_engine/pool/v1.rssrc/dbus/types.rssrc/dbus/pool/pool_3_6/methods.rssrc/engine/types/keys.rssrc/engine/strat_engine/pool/dispatch.rssrc/stratis/ipc_support/dbus_support.rssrc/dbus/manager/mod.rssrc/stratis/dm.rssrc/dbus/pool/mod.rssrc/engine/strat_engine/pool/v2.rssrc/dbus/pool/pool_3_9/mod.rssrc/dbus/util.rssrc/engine/sim_engine/pool.rssrc/stratis/timer.rssrc/dbus/manager/manager_3_9/mod.rssrc/dbus/manager/manager_3_2/mod.rssrc/dbus/manager/manager_3_0/methods.rssrc/dbus/manager/manager_3_1/mod.rssrc/dbus/manager/manager_3_0/mod.rs
📚 Learning: 2025-09-05T14:32:42.528Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3898
File: src/engine/sim_engine/pool.rs:934-948
Timestamp: 2025-09-05T14:32:42.528Z
Learning: In src/engine/sim_engine/pool.rs, the start_encrypt_pool method intentionally creates a SizedKeyMemory with 1 byte allocated but 0 length reported - this is to avoid NULL pointer issues while simulating an empty key slice in the sim engine.
Applied to files:
src/dbus/manager/manager_3_8/mod.rssrc/dbus/manager/manager_3_8/methods.rssrc/dbus/manager/manager_3_2/methods.rssrc/engine/strat_engine/pool/dispatch.rssrc/engine/sim_engine/pool.rs
🧬 Code graph analysis (52)
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
src/dbus/filesystem/filesystem_3_0/props.rs (1)
name_prop(7-9)
src/dbus/macros.rs (1)
src/bin/utils/generators/lib.rs (1)
log(26-28)
src/dbus/manager/manager_3_8/mod.rs (1)
src/dbus/manager/manager_3_8/methods.rs (1)
create_pool_method(32-130)
src/dbus/manager/manager_3_0/props.rs (1)
src/stratis/keys.rs (1)
engine(28-46)
src/dbus/pool/pool_3_0/mod.rs (1)
src/dbus/pool/pool_3_0/props.rs (4)
allocated_prop(29-31)name_prop(12-15)size_prop(17-19)used_prop(21-27)
src/dbus/filesystem/shared.rs (3)
src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Name(54-56)src/dbus/manager/manager_3_2/methods.rs (1)
guard(72-76)
src/dbus/pool/pool_3_0/props.rs (2)
src/dbus/util.rs (1)
option_to_tuple(36-41)src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)
src/dbus/filesystem/filesystem_3_0/props.rs (2)
src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Name(54-56)
src/engine/types/actions.rs (2)
src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Name(54-56)
src/dbus/manager/manager_3_8/methods.rs (5)
src/dbus/pool/mod.rs (2)
pool(53-53)register_pool(26-68)src/dbus/util.rs (7)
engine_to_dbus_err_tuple(67-73)tuple_to_option(27-33)connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)src/engine/types/keys.rs (12)
new(46-48)new(126-144)new(278-282)new(728-730)from(251-258)from(645-661)from(669-677)from(813-820)try_from(499-521)try_from(705-713)try_from(719-721)uuid(732-734)src/engine/types/mod.rs (8)
default(565-567)new(178-180)new(277-279)new(310-322)new(375-377)from(291-296)from(358-368)try_from(573-593)src/stratis/errors.rs (8)
from(165-167)from(171-173)from(177-179)from(183-185)from(189-191)from(195-197)from(201-203)from(207-209)
src/stratis/errors.rs (2)
src/dbus_api/blockdev/blockdev_3_0/api.rs (9)
f(34-34)f(41-41)f(48-48)f(57-57)f(64-64)f(71-71)f(78-78)f(85-85)f(92-92)src/dbus_api/filesystem/filesystem_3_0/api.rs (3)
f(33-33)f(40-40)f(47-47)
src/engine/engine.rs (7)
src/engine/sim_engine/pool.rs (1)
create_filesystems(221-263)src/engine/strat_engine/pool/dispatch.rs (1)
create_filesystems(111-121)src/engine/strat_engine/pool/v1.rs (1)
create_filesystems(846-895)src/engine/strat_engine/pool/v2.rs (1)
create_filesystems(751-800)src/dbus_api/pool/pool_3_0/methods.rs (1)
create_filesystems(29-129)src/dbus_api/pool/pool_3_6/methods.rs (1)
create_filesystems(21-130)src/engine/shared.rs (1)
specs(248-256)
src/dbus/pool/shared.rs (1)
src/engine/engine.rs (1)
get_pool(487-490)
src/dbus/pool/pool_3_6/mod.rs (1)
src/dbus/pool/pool_3_6/methods.rs (1)
create_filesystems_method(25-124)
src/dbus/udev.rs (1)
src/dbus/pool/mod.rs (2)
pool(53-53)register_pool(26-68)
src/dbus/blockdev/blockdev_3_0/methods.rs (1)
src/dbus_api/blockdev/blockdev_3_0/methods.rs (1)
set_user_info(16-73)
src/dbus/manager/manager_3_2/methods.rs (3)
src/dbus/filesystem/mod.rs (1)
register_filesystem(25-43)src/dbus/pool/mod.rs (1)
unregister_pool(70-84)src/dbus/util.rs (9)
engine_to_dbus_err_tuple(67-73)send_locked_pools_signals(123-145)send_stopped_pools_signals(147-160)tuple_to_option(27-33)connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)
src/dbus/filesystem/mod.rs (4)
src/dbus/util.rs (5)
connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)src/dbus/pool/pool_3_9/mod.rs (2)
connection(73-73)register(49-67)src/dbus/manager/manager_3_0/mod.rs (1)
register(53-70)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
register(30-41)
src/engine/strat_engine/pool/v1.rs (4)
src/engine/engine.rs (3)
create_filesystems(162-167)size(93-93)size(122-122)src/engine/sim_engine/pool.rs (2)
create_filesystems(221-263)new(58-77)src/engine/strat_engine/pool/dispatch.rs (1)
create_filesystems(111-121)src/engine/strat_engine/pool/v2.rs (1)
create_filesystems(751-800)
src/dbus/types.rs (1)
src/dbus/util.rs (1)
result_option_to_tuple(50-63)
src/dbus/pool/pool_3_6/methods.rs (3)
src/dbus/filesystem/mod.rs (1)
register_filesystem(25-43)src/engine/engine.rs (2)
filesystems(317-317)create_filesystems(162-167)src/engine/types/actions.rs (16)
new(235-237)new(311-313)new(586-589)changed(35-35)changed(54-59)changed(176-181)changed(200-205)changed(262-273)changed(327-333)changed(396-401)changed(518-523)changed(606-612)changed(675-680)changed(724-729)changed(759-764)changed(829-834)
src/engine/types/keys.rs (2)
src/engine/strat_engine/liminal/device_info.rs (11)
into(74-101)into(194-221)into(268-273)into(773-775)into(804-806)from(61-68)from(125-133)from(182-188)from(257-262)from(472-480)from(484-492)src/dbus/types.rs (2)
from(47-110)from(204-210)
src/engine/strat_engine/pool/dispatch.rs (6)
src/engine/engine.rs (1)
create_filesystems(162-167)src/engine/sim_engine/pool.rs (1)
create_filesystems(221-263)src/engine/strat_engine/pool/v1.rs (1)
create_filesystems(846-895)src/engine/strat_engine/pool/v2.rs (1)
create_filesystems(751-800)src/dbus_api/pool/pool_3_0/methods.rs (1)
create_filesystems(29-129)src/engine/shared.rs (1)
specs(248-256)
src/stratis/ipc_support/dbus_support.rs (4)
src/stratis/ipc_support/jsonrpc_support.rs (1)
setup(39-56)src/engine/engine.rs (1)
pools(507-507)src/engine/strat_engine/engine.rs (2)
pools(201-203)pools(739-741)src/engine/sim_engine/engine.rs (1)
pools(300-302)
src/dbus/manager/mod.rs (7)
src/dbus/types.rs (2)
from(47-110)from(204-210)src/dbus/util.rs (5)
connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)src/dbus/pool/pool_3_9/mod.rs (2)
connection(73-73)register(49-67)src/dbus/manager/manager_3_2/mod.rs (1)
register(61-78)src/dbus/manager/manager_3_1/mod.rs (1)
register(51-68)src/dbus/manager/manager_3_0/mod.rs (1)
register(53-70)src/dbus/manager/manager_3_9/mod.rs (1)
register(43-60)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/stratis/dm.rs (1)
src/dbus/util.rs (7)
send_fs_background_signals(115-121)send_pool_background_signals(76-112)connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)
src/dbus/pool/mod.rs (3)
src/dbus/blockdev/mod.rs (1)
register_blockdev(43-138)src/dbus/udev.rs (2)
register_pool(62-72)new(25-39)src/dbus/pool/pool_3_9/mod.rs (5)
connection(73-73)register(49-67)Uuid(98-100)new(33-47)unregister(69-75)
src/dbus/blockdev/blockdev_3_9/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/engine/strat_engine/pool/v2.rs (5)
src/engine/shared.rs (1)
specs(248-256)src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Name(54-56)src/engine/types/mod.rs (4)
new(178-180)new(277-279)new(310-322)new(375-377)src/engine/types/actions.rs (3)
new(235-237)new(311-313)new(586-589)
src/dbus/blockdev/blockdev_3_8/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_1/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/mod.rs (8)
new(31-37)register(39-50)SetUserInfo(57-59)Devnode(63-65)UserInfo(81-83)Pool(93-95)Uuid(99-101)Tier(105-107)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_2/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/engine/types/mod.rs (3)
src/engine/types/keys.rs (5)
uuid(732-734)from(251-258)from(645-661)from(669-677)from(813-820)src/dbus/pool/pool_3_9/mod.rs (2)
Uuid(98-100)Name(104-106)src/dbus/types.rs (1)
from(47-110)
src/dbus/pool/pool_3_9/mod.rs (5)
src/dbus/pool/pool_3_0/props.rs (4)
allocated_prop(29-31)name_prop(12-15)size_prop(17-19)used_prop(21-27)src/dbus/pool/pool_3_6/methods.rs (1)
create_filesystems_method(25-124)src/dbus/pool/shared.rs (2)
pool_prop(21-29)try_pool_prop(31-39)src/dbus/filesystem/filesystem_3_9/mod.rs (4)
new(22-28)register(30-41)Uuid(48-50)Name(54-56)src/dbus/manager/manager_3_9/mod.rs (2)
new(29-41)register(43-60)
src/dbus/util.rs (2)
src/stratis/errors.rs (9)
fmt(93-159)from(165-167)from(171-173)from(177-179)from(183-185)from(189-191)from(195-197)from(201-203)from(207-209)src/dbus/types.rs (2)
from(47-110)from(204-210)
src/dbus/mod.rs (5)
src/dbus/util.rs (7)
connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)send_fs_background_signals(115-121)send_pool_background_signals(76-112)src/dbus/blockdev/mod.rs (1)
register_blockdev(43-138)src/dbus/manager/mod.rs (1)
register_manager(112-127)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/engine/sim_engine/pool.rs (9)
src/engine/engine.rs (3)
create_filesystems(162-167)size(93-93)size(122-122)src/engine/strat_engine/pool/dispatch.rs (1)
create_filesystems(111-121)src/engine/strat_engine/pool/v1.rs (1)
create_filesystems(846-895)src/engine/strat_engine/pool/v2.rs (1)
create_filesystems(751-800)src/dbus_api/pool/pool_3_0/methods.rs (1)
create_filesystems(29-129)src/dbus_api/pool/pool_3_6/methods.rs (1)
create_filesystems(21-130)src/engine/shared.rs (1)
specs(248-256)src/engine/types/mod.rs (6)
new(178-180)new(277-279)new(310-322)new(375-377)as_ref(188-190)as_ref(412-417)src/engine/types/actions.rs (3)
new(235-237)new(311-313)new(586-589)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)
src/stratis/timer.rs (1)
src/dbus/util.rs (7)
send_fs_background_signals(115-121)send_pool_background_signals(76-112)connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)
src/dbus/blockdev/blockdev_3_3/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_5/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(37-48)
src/dbus/manager/manager_3_9/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_8/methods.rs (4)
create_pool_method(32-130)devs(47-47)key_desc(48-51)clevis_info(52-52)
src/dbus/filesystem/filesystem_3_9/mod.rs (2)
src/dbus/filesystem/filesystem_3_0/props.rs (1)
name_prop(7-9)src/dbus/filesystem/shared.rs (1)
filesystem_prop(11-27)
src/dbus/manager/manager_3_2/mod.rs (4)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_2/methods.rs (3)
refresh_state_method(202-207)start_pool_method(28-129)stop_pool_method(131-200)src/dbus/manager/manager_3_2/props.rs (1)
stopped_pools_prop(12-16)src/dbus/util.rs (5)
connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)
src/dbus/manager/manager_3_0/methods.rs (3)
src/dbus/pool/mod.rs (3)
pool(53-53)register_pool(26-68)unregister_pool(70-84)src/dbus/util.rs (8)
engine_to_dbus_err_tuple(67-73)send_locked_pools_signals(123-145)tuple_to_option(27-33)connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)src/engine/types/keys.rs (13)
new(46-48)new(126-144)new(278-282)new(728-730)key_desc(84-89)clevis_info(91-96)clevis_info(628-641)from(251-258)from(645-661)from(669-677)from(813-820)new_legacy(105-124)uuid(732-734)
src/stratis/run.rs (5)
src/dbus/mod.rs (1)
create_dbus_handler(34-55)src/stratis/ipc_support/dbus_support.rs (1)
setup(23-51)src/stratis/ipc_support/jsonrpc_support.rs (1)
setup(39-56)src/stratis/dm.rs (1)
dm_event_thread(36-110)src/stratis/timer.rs (1)
run_timers(74-88)
src/dbus/manager/manager_3_1/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (5)
connection(84-86)connection(97-99)connection(126-128)connection(135-137)connection(150-152)
src/dbus/manager/manager_3_0/mod.rs (4)
src/dbus/manager/manager_3_0/methods.rs (7)
create_pool_method(99-157)destroy_pool_method(159-206)list_keys_method(34-44)set_key_method(46-74)unlock_pool_method(208-236)unset_key_method(76-96)devs(111-111)src/dbus/manager/manager_3_0/props.rs (2)
locked_pools_prop(16-18)version_prop(12-14)src/dbus/pool/pool_3_9/mod.rs (3)
new(33-47)connection(73-73)register(49-67)src/dbus/manager/manager_3_9/mod.rs (3)
new(29-41)register(43-60)CreatePool(67-91)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: python-based-tests
- GitHub Check: checks (make -f Makefile check-typos, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile fmt-ci, 1.91.0, rustfmt)
🔇 Additional comments (22)
src/stratis/ipc_support/jsonrpc_support.rs (1)
5-5: Arc import is appropriate and matches existing usageThe added
use std::sync::Arc;cleanly aligns with theArc<dyn Engine>signatures and improves readability over fully-qualified paths. No issues here.src/engine/mod.rs (1)
18-18: Re-exportingSomeLockReadGuardlooks appropriateExposing
SomeLockReadGuardalongside the other guard types is consistent with existing exports and supports the new pool helpers without changing behavior.src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: Asyncset_user_info_methodport looks consistent with prior behaviorLookup, action dispatch, and mapping of
RenameActionand errors back to((bool, String), u16, String)match the old dbus_api logic, and there are no.awaits while holding the mutable guard. This method looks good as-is.src/dbus/manager/manager_3_2/methods.rs (1)
131-207: Stop/refresh manager methods look consistent and non-blockingThe
stop_pool_methodandrefresh_state_methodimplementations cleanly map engine results and errors into the D-Bus tuples and don’t appear to hold engine or manager locks acrossawaitpoints. Behavior forStopAction::{Identity, Stopped, Partial}and error mapping viaengine_to_dbus_err_tuplelooks coherent.src/stratis/errors.rs (2)
231-242: LGTM!The
Fromtrait implementations for the new zbus error types are correct and follow the established pattern.
54-56: No changes needed —zbus::Erroris already optimized for cheap cloning.zbus::Error implements Clone with several variants using Arc/Box internally (InputOutput is Arc, FDO is Box) and Message is Arc-backed, making cloning already cheap without additional Arc wrapping. The removal of Arc from the
Dbusvariant is intentional and correct, not an inconsistency. Other error types likeIoandSerderetain Arc because their underlying types (std::io::Error, etc.) are expensive to clone — zbus::Error doesn't have this problem.src/dbus/manager/manager_3_2/props.rs (1)
12-16: LGTM!The async property function correctly wraps the engine's
stopped_pools()result in aManagerR2type for D-Bus exposure. The implementation is clean and follows the established pattern.src/lib.rs (1)
42-42: Breaking change: public module renamed.The public module has been renamed from
dbus_apitodbus. This is a breaking change that will affect all consumers importing from thedbus_apimodule path. Ensure this is documented in release notes and migration guides.src/dbus/pool/pool_3_6/mod.rs (1)
5-7: LGTM!The module structure follows the established pattern for versioned D-Bus interfaces, with a clear re-export of the
create_filesystems_methodfrom the methods submodule.src/dbus/filesystem/filesystem_3_0/mod.rs (1)
5-7: LGTM!The module organization is clean and consistent with the versioned D-Bus interface pattern used throughout the codebase.
src/dbus/manager/manager_3_8/mod.rs (1)
5-7: LGTM!The module follows the established versioned interface pattern for manager components, with a straightforward re-export of the
create_pool_method.src/dbus/pool/pool_3_0/mod.rs (1)
5-7: LGTM!The module correctly re-exports the pool property accessors (
allocated_prop,name_prop,size_prop,used_prop) following the established pattern for versioned D-Bus interfaces.src/dbus/filesystem/filesystem_3_0/props.rs (1)
7-9: LGTM!The
name_propfunction is a simple pass-through that returns the inputName. The unused parameters (FilesystemUuidand&dyn Filesystem) are intentionally ignored, which is appropriate for maintaining a consistent function signature across property accessors.src/dbus/consts.rs (1)
1-7: Centralizing DBus constants looks goodThe base path, service name, and
OK_STRINGare clearly defined and ready to be reused across DBus modules; no issues from an API or correctness standpoint.src/dbus/manager/manager_3_0/props.rs (1)
12-18: Thin manager property helpers are correct
version_propandlocked_pools_propare simple, side-effect-free accessors that cleanly expose engine state for DBus without adding policy; implementation looks fine.src/engine/strat_engine/pool/dispatch.rs (1)
111-121: Dispatch forcreate_filesystemsmatches the updated traitThe AnyPool implementation now matches the trait’s Name-based result type and updated specs signature, and simply forwards to V1/V2 without changing behavior; all good.
src/dbus/filesystem/shared.rs (1)
11-27: Filesystem lookup helper is well-structuredThe helper correctly handles both “pool not found” and “filesystem not found” cases with clear
Error::Failedmessages, and confines the filesystem borrow to the callback scope; this looks solid.src/dbus/filesystem/mod.rs (1)
25-43: Filesystem registration helper is consistent with pool/manager registrationThe helper cleanly constructs a unique object path under
STRATIS_BASE_PATH, delegates registration toFilesystemR9::register, and then records the filesystem inManagerunder a write lock. This matches the existing registration patterns for pools/managers and looks correct.src/stratis/timer.rs (1)
22-61: DBus background signal wiring in timers looks consistentPassing
Arc<Connection>andLockable<Arc<RwLock<Manager>>>throughcheck_pool_and_fsandprocess_checksand usingsend_pool_background_signals/send_fs_background_signalsis clean and correctly gated behinddbus_enabled. CloningLockableper loop iteration is cheap and keeps the API straightforward; non‑DBus builds retain the previous behavior. No issues spotted here.Also applies to: 74-85
src/dbus/blockdev/blockdev_3_9/mod.rs (1)
22-48: BlockdevR9 interface and registration align with existing patternsThe BlockdevR9 struct, its
registerfunction, and all property getters cleanly reuseblockdev_propand the existing prop helpers. The interface name, signatures, and emits‑changed annotations are consistent with the other BlockdevR* implementations. I don’t see issues here.Also applies to: 51-151
src/dbus/manager/mod.rs (1)
34-110: Manager path/UUID bookkeeping and registration look correctThe bidirectional maps for pools, filesystems, and blockdevs are updated symmetrically in the add/get/remove methods, and
register_managerwires all ManagerR* variants plusObjectManageratSTRATIS_BASE_PATHin a straightforward way. Assuming callers consistently use the provided add/remove helpers, this should behave as intended.Also applies to: 112-127
src/dbus/blockdev/blockdev_3_6/mod.rs (1)
22-48: BlockdevR6 implementation is consistent with the other blockdev versionsThe BlockdevR6 struct,
registermethod, and property getters mirror the existing BlockdevR* pattern and correctly reuseblockdev_propplus the shared prop helpers. The interface name and signatures are appropriate for r6. No issues found here.Also applies to: 51-151
| pub async fn start_pool_method<'a>( | ||
| engine: &Arc<dyn Engine>, | ||
| connection: &Arc<Connection>, | ||
| manager: &Lockable<Arc<RwLock<Manager>>>, | ||
| counter: &Arc<AtomicU64>, | ||
| pool_uuid: PoolUuid, | ||
| unlock_method_tuple: (bool, UnlockMethod), | ||
| ) -> ( | ||
| ( | ||
| bool, | ||
| (ObjectPath<'a>, Vec<ObjectPath<'a>>, Vec<ObjectPath<'a>>), | ||
| ), | ||
| u16, | ||
| String, | ||
| ) { | ||
| let default_return = ( | ||
| false, | ||
| (ObjectPath::default(), Vec::default(), Vec::default()), | ||
| ); | ||
|
|
||
| let unlock_method = tuple_to_option(unlock_method_tuple); | ||
|
|
||
| match handle_action!( | ||
| engine | ||
| .start_pool( | ||
| PoolIdentifier::Uuid(pool_uuid), | ||
| TokenUnlockMethod::from(unlock_method), | ||
| None, | ||
| false | ||
| ) | ||
| .await | ||
| ) { | ||
| Ok(StartAction::Started(_)) => { | ||
| let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { | ||
| Some(g) => g, | ||
| None => { | ||
| return ( | ||
| default_return, | ||
| DbusErrorEnum::ERROR as u16, | ||
| format!("No pool found for newly started pool with UUID {pool_uuid}"), | ||
| ); | ||
| } | ||
| }; | ||
| let mut fs_paths = Vec::default(); | ||
| for fs_uuid in guard | ||
| .filesystems() | ||
| .into_iter() | ||
| .map(|(_, fs_uuid, _)| fs_uuid) | ||
| .collect::<Vec<_>>() | ||
| { | ||
| let fs_path = match register_filesystem( | ||
| engine, connection, manager, counter, pool_uuid, fs_uuid, | ||
| ) | ||
| .await | ||
| { | ||
| Ok(fp) => fp, | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| }; | ||
| fs_paths.push(fs_path); | ||
| } | ||
| let (pool_path, dev_paths) = | ||
| match register_pool(engine, connection, manager, counter, pool_uuid).await { | ||
| Ok(pp) => pp, | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| }; | ||
|
|
||
| if guard.is_encrypted() { | ||
| if let Err(e) = send_locked_pools_signals(connection).await { | ||
| warn!( | ||
| "Failed to send signals for changed properties for the Manager interfaces: {e}" | ||
| ); | ||
| } | ||
| } | ||
| if let Err(e) = send_stopped_pools_signals(connection).await { | ||
| warn!( | ||
| "Failed to send signals for changed properties for the Manager interfaces: {e}" | ||
| ); | ||
| } | ||
|
|
||
| ( | ||
| (true, (pool_path, dev_paths, fs_paths)), | ||
| DbusErrorEnum::OK as u16, | ||
| OK_STRING.to_string(), | ||
| ) | ||
| } |
There was a problem hiding this comment.
Avoid holding SomeLockReadGuard across await points in start_pool_method
In the StartAction::Started(_) branch, the guard from engine.get_pool(...) is kept in scope while you:
awaitinsideregister_filesystem(...)in the loop,awaitinregister_pool(...),awaitinsend_locked_pools_signals/send_stopped_pools_signals.
If SomeLockReadGuard is a real read-lock on engine/pool state (as its name suggests), this means you’re holding that lock across multiple async calls, which can lead to deadlocks or at least unnecessary contention if any of those operations try to touch engine state themselves.
You can avoid this by extracting the data you need (filesystem UUIDs and is_encrypted flag) in a small inner scope, then dropping the guard before any awaits:
- Ok(StartAction::Started(_)) => {
- let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await {
- Some(g) => g,
- None => {
- return (
- default_return,
- DbusErrorEnum::ERROR as u16,
- format!("No pool found for newly started pool with UUID {pool_uuid}"),
- );
- }
- };
- let mut fs_paths = Vec::default();
- for fs_uuid in guard
- .filesystems()
- .into_iter()
- .map(|(_, fs_uuid, _)| fs_uuid)
- .collect::<Vec<_>>()
- {
+ Ok(StartAction::Started(_)) => {
+ let (is_encrypted, fs_uuids) = {
+ let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await {
+ Some(g) => g,
+ None => {
+ return (
+ default_return,
+ DbusErrorEnum::ERROR as u16,
+ format!(
+ "No pool found for newly started pool with UUID {pool_uuid}"
+ ),
+ );
+ }
+ };
+ let fs_uuids = guard
+ .filesystems()
+ .into_iter()
+ .map(|(_, fs_uuid, _)| fs_uuid)
+ .collect::<Vec<_>>();
+ (guard.is_encrypted(), fs_uuids)
+ };
+
+ let mut fs_paths = Vec::default();
+ for fs_uuid in fs_uuids {
let fs_path = match register_filesystem(
engine, connection, manager, counter, pool_uuid, fs_uuid,
)
@@ -99,9 +121,9 @@
}
};
- if guard.is_encrypted() {
+ if is_encrypted {
if let Err(e) = send_locked_pools_signals(connection).await {
warn!(
"Failed to send signals for changed properties for the Manager interfaces: {e}"
);
}
}This keeps the behavior the same while ensuring the guard (and any underlying lock) is released before performing the async registrations and signaling.
|
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
mulkieran
force-pushed
the
blockdev-changes
branch
from
a099d76 to
dee83a8
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
src/dbus/manager/manager_3_2/methods.rs (1)
60-111: Avoid holding the pool guard across multipleawaitpoints instart_pool_methodIn the
StartAction::Started(_)arm, theguardfromengine.get_pool(...)is kept alive while you:
- loop and
awaitinsideregister_filesystem(...),awaitinregister_pool(...),awaitinsend_locked_pools_signals/send_stopped_pools_signals.If that guard encapsulates a lock on engine/pool state (which is likely), this pattern can cause unnecessary contention or even deadlocks if any of those helpers also need engine/pool locks.
You can pull the data you need under a short‑lived scope and drop the guard before the first
await, e.g.:- Ok(StartAction::Started(_)) => { - let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { - Some(g) => g, - None => { - return ( - default_return, - DbusErrorEnum::ERROR as u16, - format!("No pool found for newly started pool with UUID {pool_uuid}"), - ); - } - }; - let mut fs_paths = Vec::default(); - for fs_uuid in guard - .filesystems() - .into_iter() - .map(|(_, fs_uuid, _)| fs_uuid) - .collect::<Vec<_>>() - { + Ok(StartAction::Started(_)) => { + let (is_encrypted, fs_uuids) = { + let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { + Some(g) => g, + None => { + return ( + default_return, + DbusErrorEnum::ERROR as u16, + format!( + "No pool found for newly started pool with UUID {pool_uuid}" + ), + ); + } + }; + let fs_uuids = guard + .filesystems() + .into_iter() + .map(|(_, fs_uuid, _)| fs_uuid) + .collect::<Vec<_>>(); + (guard.is_encrypted(), fs_uuids) + }; + + let mut fs_paths = Vec::default(); + for fs_uuid in fs_uuids { let fs_path = match register_filesystem( engine, connection, manager, counter, pool_uuid, fs_uuid, ) @@ -100,7 +123,7 @@ - } - let (pool_path, dev_paths) = + } + let (pool_path, dev_paths) = match register_pool(engine, connection, manager, counter, pool_uuid).await { Ok(pp) => pp, Err(e) => { @@ -108,7 +131,7 @@ return (default_return, rc, rs); } }; - - if guard.is_encrypted() { + + if is_encrypted {This preserves behavior while ensuring the guard (and any underlying lock) is released before performing the async work.
src/dbus/pool/mod.rs (1)
33-67: UnregisterPoolR9on pool-lookup failure and drop the pool guard before awaitingIf
engine.get_pool(PoolIdentifier::Uuid(pool_uuid))returnsNone, we currently return an error but leave thePoolR9object registered on the D-Bus connection, which corrupts the object-server view. We also keep the pool guard alive across theregister_blockdevawaits. Both issues were already raised in an earlier review and are still present.You can address both with a small restructuring:
- Unregister
PoolR9before returning on theNonebranch.- Bind the pool in a
let pool = match ...expression, extract the blockdev UUIDs,drop(pool), then perform the async blockdev registrations.For example:
- PoolR9::register( - engine, - connection, - manager, - counter, - path.clone(), - pool_uuid, - ) - .await?; - - match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { - Some(pool) => { - manager.write().await.add_pool(&path, pool_uuid); - - let mut bd_paths = Vec::new(); - let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); - for dev_uuid in bd_uuids { - match register_blockdev(engine, connection, manager, counter, pool_uuid, dev_uuid).await { - Ok(op) => bd_paths.push(op), - Err(_) => { - warn!("Unable to register object path for blockdev with UUID {dev_uuid} belonging to pool {pool_uuid} on the D-Bus"); - }, - } - } - Ok((path, bd_paths)) - } - None => { - Err(StratisError::Msg(format!("Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus"))) - } - } + PoolR9::register( + engine, + connection, + manager, + counter, + path.clone(), + pool_uuid, + ) + .await?; + + let pool = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { + Some(pool) => pool, + None => { + let _ = PoolR9::unregister(connection, path.clone()).await; + return Err(StratisError::Msg(format!( + "Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus" + ))); + } + }; + + manager.write().await.add_pool(&path, pool_uuid); + + let mut bd_paths = Vec::new(); + let bd_uuids = pool + .blockdevs() + .into_iter() + .map(|(u, _, _)| u) + .collect::<Vec<_>>(); + drop(pool); + + for dev_uuid in bd_uuids { + match register_blockdev(engine, connection, manager, counter, pool_uuid, dev_uuid).await { + Ok(op) => bd_paths.push(op), + Err(_) => { + warn!( + "Unable to register object path for blockdev with UUID {dev_uuid} belonging to pool {pool_uuid} on the D-Bus" + ); + }, + } + } + + Ok((path, bd_paths))src/dbus/blockdev/blockdev_3_0/props.rs (1)
28-31:pool_propshould return the real pool object path, not/
ObjectPath::default()serializes to/, so every caller of thePoolproperty sees the D-Bus root path instead of the block device’s owning pool. That makes the Pool property essentially useless for clients trying to navigate back to the pool interface.This was already called out and is still present; it should be fixed by deriving the actual pool object path from the parent pool UUID/manager state instead of returning a placeholder.
🧹 Nitpick comments (9)
src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-20:new_physical_size_propmatches existing prop-helper patterns; stub setter is fine as a placeholderThe
new_physical_size_propimplementation is consistent with the other BlockDev property helpers (Option →(bool, String)viaoption_to_tuple) and looks correct. Theset_user_info_propstub is harmless while unused; just keep the FIXME in mind when wiring aset_UserInfomethod later.src/dbus/blockdev/blockdev_3_8/mod.rs (1)
20-151: BlockdevR8 interface and registration look consistent with the other blockdev versionsStruct layout,
registerwiring, and all exposed properties correctly reuse the shared helpers (blockdev_prop,uuid_prop,new_physical_size_prop, etc.) and follow the same D-Bus patterns as the existing Rk variants. The commented‑outset_UserInfoblock aligns with the stub setter and can be enabled later without impacting current behavior.src/dbus/manager/manager_3_5/mod.rs (1)
34-171: ManagerR5 wiring and D-Bus surface are consistent with the other ManagerRk variantsThe struct,
registerhelper, and all exposed D-Bus methods cleanly delegate to the shared helpers (*_method,version_prop,stopped_pools_prop) and reuse the existing engine/manager/counter state. Usingtypes::ManagerR2<StoppedPoolsInfo>forStoppedPoolsmatches the marshalling helpers indbus/types.rs. No issues from a correctness or concurrency standpoint.src/dbus/types.rs (1)
33-216: Double‑check innerDictvalue signatures vs. the types you’re addingFor both
LockedPoolsInfoandstopped_pools_to_valueyou construct inner dicts as:let mut dict = Dict::new(&Signature::Str, &Signature::Variant);but then add values like:
result_option_to_tuple(...)→(bool, Value<'_>),info.devices.iter().map(...).collect::<Vec<_>>()→Vec<HashMap<String, Value>>.Given the declared value signature is
Variant, it’s not obvious that these concrete types will match whatDictexpects on the wire; depending onzvariant::Dict’s runtime checks, this may either:
- produce
IncompatibleTypeerrors (triggering yourwarn!paths and silently dropping entries), or- yield a different on‑wire type than the intended
a{sv}/(b(…))shapes.It would be good to verify, e.g., by adding/adjusting tests or inspecting the exposed D‑Bus signatures with
busctl introspectto ensureLockedPoolsInfoandManagerR2/ManagerR8<StoppedPoolsInfo>actually serialize to the schema you expect. If needed, you might want to:
- store
Value/Variantexplicitly in the dicts, or- adjust
result_option_to_tupleto return a plain(bool, T)and let the dict’svaluetype be that tuple instead ofVariant.src/engine/types/mod.rs (1)
20-22: uuid! macro dbus feature-split and zvariant conversion look good; check trait usage across configs.The cfg‑split in
uuid!to addzbus::zvariant::Typeand aFrom<$ident> for zvariant::Value<'a>impl underdbus_enabledis a sensible way to keep D‑Bus concerns gated, and the conversion viauuid.simple().to_string()matches how these IDs are exposed elsewhere. One subtle point: in the dbus‑enabled branch the UUID wrappers now also deriveOrd,PartialOrd, andDefault, while the non‑dbus branch does not. That’s fine as long as any code relying on these extra traits is itself behind#[cfg(feature = "dbus_enabled")]; otherwise non‑dbus builds could fail to compile.If you want identical trait sets across configurations, you could mirror
Ord/PartialOrd/Defaultinto the non‑dbus derive as well.Also applies to: 58-105
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
39-51: Consider aligningregister’sengineparameter with other register helpers.Here
registertakesengine: Arc<dyn Engine>by value, while most manager-sideregisterhelpers take&Arc<dyn Engine>and clone inside. For consistency of the public API across these D-Bus registration functions (and to avoid requiring call sites to decide when to clone vs. move), consider switching this to&Arc<dyn Engine>and cloning inSelf::new.src/dbus/manager/mod.rs (1)
55-75: Avoid recomputingOwnedObjectPathtwice in eachadd_*helper.In
add_pool,add_filesystem, andadd_blockdev, you callOwnedObjectPath::from(path.clone())twice on the same input. You can construct it once and reuse it:pub fn add_pool(&mut self, path: &ObjectPath<'_>, uuid: PoolUuid) { - self.pool_path_to_uuid - .insert(OwnedObjectPath::from(path.clone()), uuid); - self.pool_uuid_to_path - .insert(uuid, OwnedObjectPath::from(path.clone())); + let owned = OwnedObjectPath::from(path.clone()); + self.pool_path_to_uuid.insert(owned.clone(), uuid); + self.pool_uuid_to_path.insert(uuid, owned); }Same pattern applies to
add_filesystemandadd_blockdev.src/dbus/blockdev/blockdev_3_6/mod.rs (1)
77-91: Clarify intent for the commented-outset_UserInfoproperty.There’s a
// FIXMEblock with a fully sketchedset_UserInfoproperty that’s currently commented out. If this setter isn’t part of the r6 D-Bus surface, consider removing the dead code (or moving it behind a feature flag) to reduce confusion. If it is meant to be supported eventually, it might be worth opening a tracked issue and adding a brief comment describing what’s still missing (e.g., signal emission, error handling), so the next change is straightforward.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
77-91: Resolve or remove the commented-outset_UserInfoproperty.As with R6, there’s a
// FIXMEblock containing a complete but commented-outset_UserInfoimplementation. If R5 is not meant to support this setter, consider deleting the stub to keep the versioned interface definition clean. If it is meant to be added later, a short comment or tracked issue reference explaining what’s missing would help future maintainers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (36)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/manager/manager_3_2/methods.rs(1 hunks)src/dbus/manager/manager_3_2/mod.rs(1 hunks)src/dbus/manager/manager_3_2/props.rs(1 hunks)src/dbus/manager/manager_3_3/mod.rs(1 hunks)src/dbus/manager/manager_3_4/methods.rs(1 hunks)src/dbus/manager/manager_3_4/mod.rs(1 hunks)src/dbus/manager/manager_3_5/mod.rs(1 hunks)src/dbus/manager/manager_3_6/methods.rs(1 hunks)src/dbus/manager/manager_3_6/mod.rs(1 hunks)src/dbus/manager/manager_3_7/mod.rs(1 hunks)src/dbus/manager/manager_3_8/methods.rs(1 hunks)src/dbus/manager/manager_3_8/mod.rs(1 hunks)src/dbus/manager/manager_3_8/props.rs(1 hunks)src/dbus/manager/manager_3_9/methods.rs(1 hunks)src/dbus/manager/manager_3_9/mod.rs(1 hunks)src/dbus/manager/mod.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/dbus/types.rs(1 hunks)src/dbus/util.rs(1 hunks)src/engine/types/mod.rs(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- src/dbus/blockdev/shared.rs
- src/dbus/manager/manager_3_2/props.rs
- src/dbus/manager/manager_3_8/methods.rs
- src/dbus/blockdev/mod.rs
- src/dbus/manager/manager_3_8/mod.rs
- src/dbus/blockdev/blockdev_3_7/mod.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/manager/manager_3_6/methods.rssrc/dbus/manager/manager_3_8/props.rssrc/dbus/manager/manager_3_4/methods.rssrc/dbus/manager/manager_3_3/mod.rssrc/dbus/manager/manager_3_9/methods.rssrc/dbus/manager/manager_3_9/mod.rssrc/dbus/manager/manager_3_2/mod.rssrc/dbus/blockdev/blockdev_3_0/props.rssrc/dbus/types.rssrc/dbus/pool/mod.rssrc/dbus/util.rssrc/dbus/manager/manager_3_6/mod.rssrc/dbus/manager/manager_3_7/mod.rssrc/dbus/manager/manager_3_5/mod.rssrc/dbus/manager/mod.rssrc/dbus/manager/manager_3_2/methods.rssrc/dbus/manager/manager_3_4/mod.rs
📚 Learning: 2025-09-05T14:32:42.528Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3898
File: src/engine/sim_engine/pool.rs:934-948
Timestamp: 2025-09-05T14:32:42.528Z
Learning: In src/engine/sim_engine/pool.rs, the start_encrypt_pool method intentionally creates a SizedKeyMemory with 1 byte allocated but 0 length reported - this is to avoid NULL pointer issues while simulating an empty key slice in the sim engine.
Applied to files:
src/dbus/manager/manager_3_4/methods.rssrc/dbus/manager/manager_3_9/methods.rssrc/dbus/manager/manager_3_2/methods.rs
🧬 Code graph analysis (22)
src/dbus/manager/manager_3_6/methods.rs (3)
src/dbus/pool/mod.rs (1)
unregister_pool(70-84)src/dbus/util.rs (15)
engine_to_dbus_err_tuple(70-76)send_locked_pools_signals(126-148)send_stopped_pools_signals(150-226)connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/manager/manager_3_2/methods.rs (1)
stop_pool_method(131-199)
src/dbus/manager/manager_3_4/methods.rs (3)
src/dbus/filesystem/mod.rs (1)
register_filesystem(25-43)src/dbus/util.rs (16)
engine_to_dbus_err_tuple(70-76)send_locked_pools_signals(126-148)send_stopped_pools_signals(150-226)tuple_to_option(30-36)connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus_api/api/manager_3_2/methods.rs (1)
start_pool(22-129)
src/dbus/manager/manager_3_3/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)
src/engine/types/mod.rs (2)
src/engine/types/keys.rs (5)
uuid(732-734)from(251-258)from(645-661)from(669-677)from(813-820)src/dbus/types.rs (1)
from(52-115)
src/dbus/manager/manager_3_9/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_8/methods.rs (4)
create_pool_method(40-138)key_desc(56-59)devs(55-55)clevis_info(60-60)src/dbus/manager/manager_3_8/mod.rs (3)
Version(87-89)StoppedPools(93-95)ListKeys(98-100)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/manager/manager_3_2/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_2/methods.rs (2)
start_pool_method(28-129)stop_pool_method(131-199)src/dbus/manager/manager_3_2/props.rs (1)
stopped_pools_prop(12-16)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (1)
uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/types.rs (1)
src/dbus/util.rs (1)
result_option_to_tuple(53-66)
src/dbus/blockdev/blockdev_3_9/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/blockdev/blockdev_3_0/mod.rs (8)
new(31-37)Devnode(63-65)HardwareInfo(69-77)UserInfo(81-83)InitializationTime(87-89)Pool(93-95)Uuid(99-101)Tier(105-107)
src/dbus/util.rs (1)
src/stratis/errors.rs (1)
fmt(93-159)
src/dbus/blockdev/blockdev_3_3/mod.rs (7)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/blockdev/blockdev_3_0/mod.rs (10)
new(31-37)register(39-50)Devnode(63-65)HardwareInfo(69-77)InitializationTime(87-89)Pool(93-95)Uuid(99-101)Tier(105-107)PhysicalPath(111-119)TotalPhysicalSize(123-131)src/dbus/blockdev/blockdev_3_1/mod.rs (10)
new(27-33)register(35-46)Devnode(59-61)HardwareInfo(65-73)InitializationTime(83-85)Pool(89-91)Uuid(95-97)Tier(101-103)PhysicalPath(107-115)TotalPhysicalSize(119-127)src/dbus/blockdev/blockdev_3_2/mod.rs (10)
new(27-33)register(35-46)Devnode(59-61)HardwareInfo(65-73)InitializationTime(83-85)Pool(89-91)Uuid(95-97)Tier(101-103)PhysicalPath(107-115)TotalPhysicalSize(119-127)src/dbus/blockdev/blockdev_3_4/mod.rs (11)
new(29-35)register(37-48)Devnode(55-57)HardwareInfo(61-69)InitializationTime(95-97)Pool(101-103)Uuid(107-109)Tier(113-115)PhysicalPath(119-127)TotalPhysicalSize(131-139)NewPhysicalSize(143-151)
src/dbus/manager/manager_3_6/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_2/methods.rs (1)
refresh_state_method(201-206)
src/dbus/manager/manager_3_7/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)
src/dbus/blockdev/blockdev_3_5/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/mod.rs (5)
src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/pool/pool_3_9/mod.rs (2)
connection(73-73)new(33-47)src/dbus/blockdev/mod.rs (1)
register_blockdev(43-138)src/dbus/manager/mod.rs (1)
register_manager(123-144)src/dbus/udev.rs (1)
new(25-39)
src/dbus/manager/manager_3_5/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)
src/dbus/manager/mod.rs (10)
src/dbus/manager/manager_3_8/mod.rs (1)
register(62-79)src/dbus/manager/manager_3_9/mod.rs (1)
register(61-78)src/dbus/manager/manager_3_7/mod.rs (1)
register(57-74)src/dbus/manager/manager_3_6/mod.rs (1)
register(60-77)src/dbus/manager/manager_3_5/mod.rs (1)
register(56-73)src/dbus/manager/manager_3_4/mod.rs (1)
register(59-76)src/dbus/manager/manager_3_3/mod.rs (1)
register(57-74)src/dbus/manager/manager_3_2/mod.rs (1)
register(58-75)src/dbus/manager/manager_3_0/mod.rs (1)
register(53-70)src/dbus/manager/manager_3_1/mod.rs (1)
register(51-68)
src/dbus/manager/manager_3_2/methods.rs (4)
src/dbus/filesystem/mod.rs (1)
register_filesystem(25-43)src/dbus/pool/mod.rs (1)
unregister_pool(70-84)src/dbus/util.rs (15)
engine_to_dbus_err_tuple(70-76)send_locked_pools_signals(126-148)send_stopped_pools_signals(150-226)connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/manager/manager_3_6/methods.rs (1)
stop_pool_method(21-100)
src/dbus/blockdev/blockdev_3_2/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/mod.rs (4)
new(31-37)Pool(93-95)Uuid(99-101)Tier(105-107)
src/dbus/manager/manager_3_4/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/stratis/keys.rs (1)
engine(28-46)src/dbus/manager/manager_3_4/methods.rs (1)
start_pool_method(28-142)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (30)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile check-typos, 1.91.0, cargo)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: python-based-tests
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
🔇 Additional comments (42)
src/dbus/manager/manager_3_8/props.rs (1)
1-16: Thin D‑Bus adapter looks correct and consistent with existing patternsThis helper cleanly wraps
engine.stopped_pools().awaitintoManagerR8<StoppedPoolsInfo>, with appropriate async usage and types. The&Arc<dyn Engine>parameter matches the established pattern from other manager versions and avoids unnecessary cloning. No issues from a correctness or API‑shape standpoint.src/dbus/manager/manager_3_2/methods.rs (1)
131-198:stop_pool_methodandrefresh_state_methodmatch existing patterns and look correct
stop_pool_methodmirrors the established 3.6 implementation: resolvesPoolUuid, callsengine.stop_pool, unregisters onStopped/Partial, and sends stopped/locked pool signals with sensible warnings on failure.refresh_state_methodcleanly wrapsengine.refresh_state()and reusesengine_to_dbus_err_tuplefor error mapping.No issues spotted here.
src/dbus/types.rs (1)
14-32: Overall D-Bus type/marshalling additions look coherentThe
FilesystemSpecalias,ManagerR2/ManagerR8wrappers,DbusErrorEnum, and theType/From<Value>impls forLockedPoolsInfo,ManagerR2<StoppedPoolsInfo>,ManagerR8<StoppedPoolsInfo>, andPoolUuidall fit cleanly into the existing D-Bus typing scheme and align with how these types are consumed by the new Manager interfaces.Also applies to: 222-281
src/dbus/blockdev/blockdev_3_1/mod.rs (1)
49-127: Blockdev R1 wiring mirrors the shared helpersThe SetUserInfo method and all property accessors cleanly delegate to the established blockdev helpers with the correct signal semantics, so R1 stays consistent with the prior surfaces. Nicely done.
src/dbus/manager/manager_3_2/mod.rs (1)
58-172: ManagerR2 surface composes the shared helpers cleanlyRegistration threads the shared state through as expected, and each D-Bus entry point defers to the existing helper logic, so behavior stays aligned with previous revisions. Looks good to me.
src/dbus/manager/manager_3_9/methods.rs (1)
31-154: R9 StartPool flow matches expectationsThe expanded parameter handling (ID parsing, unlock options, key FD, remove-cache) integrates cleanly with the existing registration/signal flow, so the R9 surface should behave in line with earlier versions.
src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: SetUserInfo helper reuse is spot onThe helper fetches the pool mutably, forwards to
set_blockdev_user_info, and maps each outcome to the established D-Bus tuple format, so the new interface hook stays in sync with engine behavior.src/dbus/manager/manager_3_6/methods.rs (1)
21-100: StopPool ID routing looks solidParsing either UUID or name into
PoolIdentifierand then driving the usual unregister/signal flow keeps the method consistent with previous versions while expanding the call surface—looks good.src/dbus/manager/manager_3_4/methods.rs (1)
28-142: R4 StartPool remains aligned with shared flowThe method still performs the expected ID parsing, pool/filesystem registration, and signal emission steps, so the R4 surface stays behaviorally consistent.
src/dbus/manager/manager_3_3/mod.rs (2)
35-75: ManagerR3 struct and registration pattern look consistent.The struct field choices,
new()constructor, andregister()implementation (cloning Arcs/Lockable and registering atSTRATIS_BASE_PATH) match the established pattern for other manager versions and integrate cleanly withregister_manager.
77-171: Confirm StoppedPools wrapper version choice for the r3 interface.The
StoppedPoolsproperty onManagerR3returnstypes::ManagerR2<StoppedPoolsInfo>while exposing theorg.storage.stratis3.Manager.r3interface. This follows the pattern of reusing earlier wrapper versions when the schema is unchanged, but please double‑check thatManagerR2is indeed the intended D‑Bus type for r3 here. The rest of the methods delegating to shared helpers (*_method/*_prop) look consistent.src/dbus/mod.rs (1)
34-55: create_dbus_handler wiring is coherent and side‑effect ordering is sound.Counter, shared
Manager, and system connection are initialized once and then consistently passed toregister_managerandUdevHandler::new. The returned(Arc<Connection>, UdevHandler, Lockable<Arc<RwLock<Manager>>>)neatly exposes the pieces needed by the caller without leaking unnecessary internals.src/dbus/manager/manager_3_9/mod.rs (1)
39-187: ManagerR9 implementation follows existing patterns; verify StoppedPools wrapper choice.The
ManagerR9struct,new()/register()helpers, and interface methods cleanly mirror earlier manager versions, delegating all behavior to the shared*_method/*_prophelpers (including the newstart_pool_methodfrom this module). The only subtle point isStoppedPoolsreturningtypes::ManagerR8<StoppedPoolsInfo>on the r9 interface; that reuse makes sense if the D‑Bus schema for this property is unchanged from r8, but it’s worth confirming that this is intentional.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
22-151: BlockdevR4 cleanly reuses shared property helpers and registration logic.The
BlockdevR4struct,register()helper, andorg.storage.stratis3.blockdev.r4interface are wired consistently with earlier blockdev revisions: properties all go throughblockdev_propwith the existing 3_0/3_3 prop functions, and the registration simply attaches the instance to the given object path. This doesn’t introduce any new behavior around the existingPoolpath FIXME, so there’s no regression there.src/engine/types/mod.rs (1)
108-266: Name and ClevisInfo types integrate cleanly with the new D‑Bus plumbing.The
ClevisInfoalias clarifies tuple semantics, and splittingName’s definition via cfg to addType/Valuederives (withsignature = "s") only whendbus_enabledis active keeps the core engine representation unchanged while making D‑Bus serialization straightforward. UsingNameas the key in thename_to_uuidmaps forLockedPoolsInfoandStoppedPoolsInfoaligns well with theBorrow<str>/Deref<str>implementations and should behave just likeStringkeys from a caller’s perspective.src/dbus/blockdev/blockdev_3_3/mod.rs (1)
24-153: BlockdevR3 D-Bus wiring looks consistent with other versionsThe struct,
register()helper, and all property accessors correctly follow the established pattern (usingblockdev_propwith the 3_0 props plusnew_physical_size_prop), and I don’t see functional issues here.src/dbus/pool/mod.rs (1)
70-84: unregister_pool flow looks sound
unregister_poolcleanly unregistersPoolR9from the object server, then removes the pool mapping fromManager, returning the UUID; the error path for a missing mapping is explicit. I don’t see issues here.src/dbus/blockdev/blockdev_3_0/props.rs (1)
12-26: Other BlockDev property accessors look correct
devnode_prop,hardware_info_prop,init_time_prop, andphysical_path_propmap cleanly onto theBlockDevtrait (paths, hardware info, init time, and devnode), and their types align with the D-Bus surface expectations.src/dbus/blockdev/blockdev_3_9/mod.rs (1)
22-151: BlockdevR9 interface is wired consistently with other blockdev revisionsThe struct,
register()helper, and property implementations correctly reuse the shared 3_0 props andnew_physical_size_prop, following the same pattern as earlier revisions. I don’t see functional or API-shape problems here.src/dbus/util.rs (2)
29-76: DBus utility conversions and error mapping look correctThe
tuple_to_option/option_to_tuple/result_option_to_tuplehelpers implement the documented contract for representing optional values and fetch errors on D-Bus, andengine_to_dbus_err_tuplesensibly normalizesStratisErrorinto the(code, message)tuple usingDbusErrorEnum::ERROR. No functional issues spotted.
78-226: Pool and manager background-signal helpers are reasonable
send_pool_background_signals,send_fs_background_signals,send_locked_pools_signals, andsend_stopped_pools_signalsall follow a straightforward pattern: resolve the relevant interface from the object server, then emit the appropriate signals, short-circuiting on errors via?. The lock usage and signal emission ordering look fine.src/dbus/blockdev/blockdev_3_6/mod.rs (1)
51-151: BlockdevR6 interface wiring looks consistent with shared helpers and other versions.The struct fields,
registerhelper, and property implementations all follow the same pattern as other blockdev versions, delegating cleanly toblockdev_propand the shared prop functions (includingnew_physical_size_prop). I don’t see correctness issues in this wiring.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
51-151: BlockdevR5 property delegation and registration pattern look correct.The D-Bus interface definition for r5 closely follows the established pattern: registration via
register, and all properties delegate toblockdev_propand the shared prop helpers (includingnew_physical_size_prop). I don’t see functional issues here.src/dbus/blockdev/blockdev_3_2/mod.rs (1)
20-128: BlockdevR2 cleanly reuses the 3.0 helpers; no issues spotted.Struct layout,
register,SetUserInfo, and all property getters are consistent with BlockdevR0, correctly reusingset_user_info_methodand the shared prop functions fromblockdev_3_0. The D-Bus types and signatures look coherent; I don’t see anything that needs changing here.src/dbus/manager/manager_3_7/mod.rs (1)
35-172: ManagerR7 interface is a consistent forwarder to shared manager helpers.The struct fields,
new/registerhelpers, and all D-Bus methods/properties mirror the existing ManagerR* versions and correctly delegate tocreate_pool_method,destroy_pool_method,list_keys_method,set_key_method,unset_key_method,start_pool_method,stop_pool_method,refresh_state_method, andstopped_pools_prop. Argument ordering and result types look coherent; I don’t see functional issues here.src/dbus/manager/mod.rs (1)
123-144: Code pattern is correct per zbus documentation.zbus's
ObjectServer::atsupports registering multiple different interface implementors on the same object path and will add distinct interfaces side-by-side. It only refuses/returns false if the same interface (same interface name) is already registered at that path.The
register_manager()function correctly registers each of the ManagerR0 through ManagerR9 types (distinct interfaces) along withfdo::ObjectManageronSTRATIS_BASE_PATHvia repeatedat(...)calls. Since these are different interface names, they will coexist without conflict.src/dbus/manager/manager_3_6/mod.rs (8)
1-36: LGTM!The imports and module structure follow the established pattern for versioned manager interfaces. The re-export of
stop_pool_methodis appropriate given that this version introduces changes to the StopPool API.
38-43: LGTM!The struct definition correctly mirrors the pattern used in other manager versions with appropriate shared ownership types for concurrent D-Bus operations.
45-78: LGTM!The constructor and registration logic follow the established pattern for versioned manager interfaces with proper Arc cloning and async D-Bus registration.
80-93: LGTM!Properties are correctly defined with appropriate signal emission behavior and delegate to shared helper functions following the established pattern.
95-112: LGTM!Key management methods correctly delegate to the shared implementations from manager_3_0 with appropriate signatures and return types.
167-170: Note the API harmonization with StartPool.The StopPool method in R6 uses
idandid_typeparameters (matching StartPool's pattern), whereas R4's StopPool accepts anObjectPath. This harmonization improves API consistency by allowing pools to be stopped using the same identifier types as starting them.
114-134: LGTM!CreatePool correctly omits the
redundancyparameter that was present in R4, reflecting intentional API evolution. The method properly delegates tocreate_pool_methodwith all required parameters.
136-165: LGTM!DestroyPool, StartPool, and RefreshState methods correctly delegate to their underlying implementations with appropriate parameters and return types.
Also applies to: 172-175
src/dbus/manager/manager_3_4/mod.rs (8)
1-35: LGTM!The imports correctly reference
stop_pool_methodfrom manager_3_2 (pre-existing) and re-exportstart_pool_methodas a new capability introduced in this version. The module structure follows the established pattern.
37-42: LGTM!The struct definition is identical to ManagerR6 with appropriate shared ownership types.
44-77: LGTM!Constructor and registration logic match the established pattern with proper Arc cloning and async D-Bus registration.
79-92: LGTM!Properties are correctly defined with appropriate signal emission behavior and delegation to shared helper functions.
94-111: LGTM!Key management methods correctly delegate to shared implementations with appropriate signatures.
115-134: Unused redundancy parameter is acceptable for API compatibility.The
_redundancyparameter is marked as unused with the underscore prefix, which correctly suppresses compiler warnings while maintaining API compatibility with the D-Bus interface contract for version 3.4. This parameter is removed in later versions (e.g., R6).
167-170: Note: StopPool API evolves in R6.This R4 implementation uses
ObjectPathfor the pool parameter, while R6 changes toidandid_typeparameters (matching StartPool's pattern). Both implementations correctly delegate to their respectivestop_pool_methodimplementations.
136-139: LGTM!DestroyPool, StartPool, and RefreshState methods correctly delegate to their underlying implementations with appropriate parameters and return types.
Also applies to: 141-165, 172-175
mulkieran
force-pushed
the
blockdev-changes
branch
from
5a86243 to
bb7efca
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/dbus/blockdev/mod.rs (1)
43-140: register_blockdev flow looks good; consider a couple of small cleanupsThe overall orchestration (unique path via atomic counter, sequential BlockdevR0..R9 registration on that path, and final
Manager::add_blockdevupdate) looks sound and easy to follow.A few non-blocking nits you might consider:
- The lifetime parameter
'aonregister_blockdevdoesn’t seem to buy much, sincepathis built from an ownedString(ObjectPath::try_from(format!(...))), which should yield an ownedObjectPath. You could simplify the signature to something like-> StratisResult<ObjectPath<'static>>(or justObjectPath<'_>) and drop the explicit lifetime to reduce generic noise.- The
counter.fetch_add(1, Ordering::AcqRel)use is stronger than necessary if this counter is only used to generate unique IDs and isn’t synchronizing with other state;Ordering::Relaxedwould be sufficient and more idiomatic for a plain monotonic ID.- Depending on how
Lockableis defined,manager: &Lockable<Arc<RwLock<Manager>>>may be more layers of locking/indirection than you need. If the intent is simply to mutateManagerunder a single lock, collapsing this to a single layer (e.g.,Lockable<Manager>orArc<RwLock<Manager>>) would makemanager.write().await.add_blockdev(..)more obviously operate on theManageritself.None of these are correctness issues; just possible simplifications if they fit the broader design.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/dbus/pool/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/blockdev_3_0/mod.rs
🧬 Code graph analysis (2)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-31)tier_prop(37-39)total_physical_size_prop(33-35)user_info_prop(41-44)uuid_prop(46-49)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(46-58)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(37-48)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (32)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
🔇 Additional comments (1)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
24-58: BlockdevR0 struct and register wiring look correctStoring
parent_object_pathas aStringinBlockdevR0and passing the validatedObjectPathonly at construction time cleanly sidesteps lifetime headaches for thePoolproperty. Theregisterhelper is straightforward: it builds the object with the expectedengine,parent_path, and UUIDs, and callsobject_server().at(path, blockdev); assuming the existingFrom<zbus::Error>/From<zvariant::Error>conversions intoStratisResultare in place elsewhere, this piece looks good to me.
mulkieran
force-pushed
the
blockdev-changes
branch
from
bb7efca to
15eec29
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
src/dbus/pool/mod.rs (1)
48-67: Tear down the D-Bus object when the pool lookup fails.The
PoolR9object is registered (lines 38-46) before verifying thatengine.get_pool()still returns the pool. Ifget_pool()returnsNone, the function returns an error (line 65) without unregistering thePoolR9object. This leaves the object pinned in the connection's object server, corrupting the D-Bus view and creating inconsistent manager mappings.Unregister the
PoolR9object before returning the error:match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { Some(pool) => { manager.write().await.add_pool(&path, pool_uuid); let mut bd_paths = Vec::new(); let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); for dev_uuid in bd_uuids { match register_blockdev(engine, connection, manager, counter, &path, pool_uuid, dev_uuid).await { Ok(op) => bd_paths.push(op), Err(_) => { warn!("Unable to register object path for blockdev with UUID {dev_uuid} belonging to pool {pool_uuid} on the D-Bus"); }, } } Ok((path, bd_paths)) } None => { + let _ = PoolR9::unregister(connection, path.clone()).await; Err(StratisError::Msg(format!("Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus"))) } }
🧹 Nitpick comments (1)
src/dbus/pool/mod.rs (1)
53-61: Drop the pool before blockdev registration to avoid holding locks unnecessarily.The
poolvariable obtained on line 49 is used only on line 53 to extract blockdev UUIDs. However, it remains in scope through line 61 during the blockdev registration loop, potentially holding internal locks that could block other operations.Extract the UUIDs and explicitly drop the pool reference before the loop:
let mut bd_paths = Vec::new(); let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); + drop(pool); for dev_uuid in bd_uuids {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/dbus/blockdev/blockdev_3_0/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/pool/mod.rs
🧬 Code graph analysis (2)
src/dbus/pool/mod.rs (1)
src/dbus/pool/pool_3_9/mod.rs (5)
connection(73-73)register(49-67)Uuid(98-100)new(33-47)unregister(69-75)
src/dbus/blockdev/mod.rs (1)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(46-58)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
🔇 Additional comments (4)
src/dbus/blockdev/mod.rs (2)
1-31: LGTM!The module structure, imports, and declarations are well-organized and appropriate for the multi-version blockdev registration pattern.
32-41: LGTM!The re-export structure provides a clean public API for all blockdev revision interfaces.
src/dbus/pool/mod.rs (2)
1-24: LGTM!The module structure and imports are well-organized and follow consistent patterns with the blockdev module.
70-84: LGTM!The
unregister_poolfunction correctly unregisters the D-Bus object, removes the manager mapping, and returns the associated UUID. The error handling and lock scope are appropriate.
| pub async fn register_blockdev<'a>( | ||
| engine: &Arc<dyn Engine>, | ||
| connection: &Arc<Connection>, | ||
| manager: &Lockable<Arc<RwLock<Manager>>>, | ||
| counter: &Arc<AtomicU64>, | ||
| pool_object_path: &ObjectPath<'_>, | ||
| pool_uuid: PoolUuid, | ||
| dev_uuid: DevUuid, | ||
| ) -> StratisResult<ObjectPath<'a>> { | ||
| let path = ObjectPath::try_from(format!( | ||
| "{}/{}", | ||
| consts::STRATIS_BASE_PATH, | ||
| counter.fetch_add(1, Ordering::AcqRel), | ||
| ))?; | ||
| BlockdevR0::register( | ||
| engine.clone(), | ||
| connection, | ||
| pool_object_path.clone(), | ||
| pool_uuid, | ||
| path.clone(), | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR1::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR2::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR3::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR4::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR5::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR6::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR7::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR8::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| BlockdevR9::register( | ||
| engine.clone(), | ||
| connection, | ||
| path.clone(), | ||
| pool_uuid, | ||
| dev_uuid, | ||
| ) | ||
| .await?; | ||
| manager.write().await.add_blockdev(&path, dev_uuid); | ||
| Ok(path) | ||
| } |
There was a problem hiding this comment.
Roll back partial registrations on error.
If any BlockdevRX::register call fails (e.g., BlockdevR5::register on line 98), the function returns immediately via ?, leaving previously registered blockdev interfaces (BlockdevR0 through BlockdevR4) pinned in the D-Bus object server. The Manager update on line 138 never executes, creating an inconsistent state where orphaned D-Bus objects exist without corresponding manager mappings.
Consider wrapping the registration sequence in error handling that unregisters previously registered interfaces on failure. For example:
pub async fn register_blockdev<'a>(
engine: &Arc<dyn Engine>,
connection: &Arc<Connection>,
manager: &Lockable<Arc<RwLock<Manager>>>,
counter: &Arc<AtomicU64>,
pool_object_path: &ObjectPath<'_>,
pool_uuid: PoolUuid,
dev_uuid: DevUuid,
) -> StratisResult<ObjectPath<'a>> {
let path = ObjectPath::try_from(format!(
"{}/{}",
consts::STRATIS_BASE_PATH,
counter.fetch_add(1, Ordering::AcqRel),
))?;
// Register all interfaces, rolling back on error
if let Err(e) = async {
BlockdevR0::register(
engine.clone(),
connection,
pool_object_path.clone(),
pool_uuid,
path.clone(),
dev_uuid,
)
.await?;
BlockdevR1::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR2::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR3::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR4::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR5::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR6::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR7::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR8::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
BlockdevR9::register(engine.clone(), connection, path.clone(), pool_uuid, dev_uuid).await?;
Ok::<_, StratisError>(())
}.await {
// Unregister all interfaces on error
let _ = connection.object_server().remove::<BlockdevR0, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR1, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR2, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR3, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR4, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR5, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR6, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR7, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR8, _>(&path).await;
let _ = connection.object_server().remove::<BlockdevR9, _>(&path).await;
return Err(e);
}
manager.write().await.add_blockdev(&path, dev_uuid);
Ok(path)
}🤖 Prompt for AI Agents
In src/dbus/blockdev/mod.rs around lines 43 to 140, the sequence of
BlockdevR*.register calls can leave previously-registered D-Bus interfaces
pinned if a later register call fails; wrap the whole registration sequence in a
fallible async block and on error call
connection.object_server().remove::<BlockdevR#,&_>(&path).await for each
previously-registered interface (ignore/remove any errors) to unregister them,
then return the original error; only call
manager.write().await.add_blockdev(&path, dev_uuid) after the registration block
succeeds.
15eec29 to
ea1c286
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
src/dbus/pool/mod.rs (2)
52-61: Document the partial blockdev registration behavior.The function logs warnings and continues when individual
register_blockdevcalls fail (lines 57-59), ultimately returning success with an incomplete list of blockdev paths. This creates a pool D-Bus object with some blockdevs missing from the D-Bus interface. While this may be an intentional design choice to maximize availability, consider adding a doc comment toregister_poolexplaining this behavior so callers understand that the returnedVec<ObjectPath>may not include all blockdevs.
38-67: Unregister PoolR9 on the error path when pool lookup fails.Despite the previous review comment being marked as "Addressed," the code still registers
PoolR9(lines 38-46) before verifying the pool exists viaengine.get_pool()(line 48). Ifget_pool()returnsNone(lines 64-66), the function returns an error without callingPoolR9::unregister(), leaving the pool object pinned in the D-Bus object server and creating an inconsistent state.Apply this diff to unregister the pool on the error path:
None => { + let _ = PoolR9::unregister(connection, path.clone()).await; Err(StratisError::Msg(format!("Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus"))) }src/dbus/blockdev/mod.rs (1)
43-138: Roll back partial registrations on error.This is a duplicate of a previous review comment, but the issue remains unaddressed: if any
BlockdevR{N}::registercall fails (e.g., line 96-103 for R5), the function returns immediately via?, leaving previously registered blockdev interfaces (R0 through R4) pinned in the D-Bus object server. The manager update on line 136 never executes, creating an inconsistent state where orphaned D-Bus objects exist without corresponding manager mappings.The previous review suggested wrapping the registration sequence in error handling that unregisters previously registered interfaces on failure. Please refer to the existing comment for the detailed implementation approach.
🧹 Nitpick comments (1)
src/dbus/types.rs (1)
283-302: Dead code annotations suggest future usage.Both
OwnedParentPool(line 288) andParentPool::to_owned(line 295) are marked with#[allow(dead_code)]but are fully implemented. This suggests they may be needed for future work or are kept for API completeness. If they're truly unused and not planned for future use, consider removing them to reduce maintenance burden.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/dbus/blockdev/mod.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/dbus/types.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/pool/mod.rssrc/dbus/types.rssrc/dbus/blockdev/mod.rs
🧬 Code graph analysis (4)
src/dbus/mod.rs (4)
src/dbus/manager/manager_3_9/mod.rs (1)
new(47-59)src/dbus/manager/manager_3_0/mod.rs (1)
new(39-51)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/dbus/pool/mod.rs (2)
src/dbus/blockdev/mod.rs (1)
register_blockdev(43-138)src/dbus/pool/pool_3_9/mod.rs (5)
connection(73-73)register(49-67)Uuid(98-100)new(33-47)unregister(69-75)
src/dbus/types.rs (3)
src/dbus/util.rs (1)
result_option_to_tuple(53-66)src/dbus/manager/manager_3_8/mod.rs (1)
new(48-60)src/dbus/manager/manager_3_2/mod.rs (1)
new(44-56)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(37-48)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (32)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: python-based-tests
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
🔇 Additional comments (4)
src/dbus/mod.rs (1)
35-56: LGTM!The
create_dbus_handlerinitialization flow is clear and well-structured. The function properly sequences the creation of shared state (counter, manager), D-Bus connection setup, manager registration, and UdevHandler construction before returning the initialized components.src/dbus/pool/mod.rs (1)
70-84: LGTM!The
unregister_poolfunction correctly unregisters the PoolR9 object, retrieves the UUID from the manager, removes the pool mapping, and returns the UUID.src/dbus/types.rs (2)
33-116: LGTM!The
TypeandFromimplementations forLockedPoolsInfocorrectly construct nested D-Bus dictionary structures. The error handling pattern (logging warnings and continuing) is appropriate for D-Bus serialization, ensuring that failures in individual field conversions don't prevent the entire structure from being serialized.
118-220: LGTM!The
stopped_pools_to_valuehelper and the ManagerR2/ManagerR8 wrapper implementations correctly serialize stopped pool information to D-Bus format. Themetadataparameter appropriately controls whether metadata_version and features fields are included, differentiating between the R2 and R8 API versions.
mulkieran
force-pushed
the
blockdev-changes
branch
from
ea1c286 to
d9179ec
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
src/dbus/blockdev/mod.rs (1)
43-138: Partial registration rollback concern already notedThe sequence of
BlockdevR0–BlockdevR9::registercalls still short-circuits on the first error, potentially leaving earlier interfaces registered on the object server without a corresponding manager entry. I see coderabbitai’s earlier comment already called this out with a concrete rollback pattern; that feedback still applies to the current version of this function.src/dbus/pool/mod.rs (2)
26-68: Previous cleanup concern may still apply: pool object persists after get_pool failure.The past review flagged that
PoolR9::register(line 38-46) succeeds before checkingengine.get_pool(line 48), and if the pool lookup returnsNone, the D-Bus object remains registered while an error is returned. The previous review comment indicates this was addressed in earlier commits, but the current code still shows the same pattern. Verify whether:
- The fix was applied differently than expected, or
- The code reverted to the original state.
If the issue remains, consider calling
PoolR9::unregisteron the error path before returning theStratisError.
52-61: Acknowledge partial blockdev registration behavior.As noted in previous reviews, individual blockdev registration failures are logged but don't fail the overall pool registration. This creates a partial-success scenario where some blockdevs aren't exposed on D-Bus. While this maximizes availability, the return type doesn't distinguish partial from complete success. Consider whether the API contract should be clarified or the return type adjusted to signal incomplete registration.
🧹 Nitpick comments (6)
src/dbus/blockdev/blockdev_3_8/mod.rs (1)
71-91: Commented-outset_UserInfoFIXME: either plan it or trim itThe active properties on
BlockdevR8are wired correctly and mirror the R3 pattern, includingNewPhysicalSizevianew_physical_size_prop. The only thing that stands out is the// FIXMEblock forset_UserInfo.If you don’t expect to implement the writable property soon, consider dropping the commented-out code (and possibly opening a tracking issue instead) to keep this module focused on the behavior that actually exists today.
src/dbus/mod.rs (1)
35-55:create_dbus_handlercomposes connection, manager, and udev cleanlyThe handler factory cleanly encapsulates: counter setup, shared
Managercreation, system-busConnectioncreation with the correct service name, manager registration, andUdevHandlerconstruction. The sharing and lifetimes (Arc/Lockable<Arc<RwLock<Manager>>>) all look consistent with the rest of the D-Bus stack.If you later need more flexible testing (e.g., injecting a non-system connection), you could consider an overload or a small internal helper that takes a pre-built
Connection, but that’s not necessary for this PR.src/dbus/blockdev/mod.rs (1)
51-55: Atomic counter can likely useRelaxedorderingFor generating unique numeric suffixes for object paths, there’s no cross-thread data dependency on the incremented value beyond uniqueness. You could simplify to
Ordering::Relaxedhere without changing behavior:- counter.fetch_add(1, Ordering::AcqRel), + counter.fetch_add(1, Ordering::Relaxed),This is micro-optimisation only; feel free to defer if you prefer the stronger ordering for consistency.
src/dbus/blockdev/blockdev_3_3/mod.rs (1)
20-153: BlockdevR3 implementation andNewPhysicalSizewiring look goodThe struct,
register()function, and all property accessors (includingNewPhysicalSizevia the localpropsmodule) follow the established blockdev patterns and use the shared helpers correctly. The only nit is the commented-outset_UserInfoFIXME block, which you might eventually either implement or drop as in the R8 module to avoid long-lived dead code, but functionally this module looks solid.src/dbus/blockdev/blockdev_3_4/mod.rs (2)
77-91: Consider tracking the FIXME or removing dead code.The commented-out
set_UserInfomethod appears across multiple BlockdevR* versions. If this is deferred work, consider opening an issue to track it; otherwise, removing the commented code would reduce clutter.Would you like me to help track this across all affected files or open an issue for the missing setter implementation?
51-152: Property implementation is solid; consider reducing duplication across versions.The D-Bus interface implementation correctly delegates to shared property helpers and sets appropriate signal emission semantics. However, BlockdevR4 (and R0, R2, R5, R6, R7) share nearly identical property accessor patterns, which could benefit from macro-based code generation or trait-based delegation to reduce maintenance burden.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/dbus/types.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/dbus/blockdev/blockdev_3_9/mod.rs
- src/dbus/blockdev/blockdev_3_0/props.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/pool/mod.rssrc/dbus/blockdev/mod.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/types.rs
🧬 Code graph analysis (10)
src/dbus/mod.rs (4)
src/dbus/manager/mod.rs (1)
register_manager(123-144)src/dbus/types.rs (1)
new(290-295)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/dbus/blockdev/blockdev_3_8/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/types.rs (1)
new(290-295)
src/dbus/blockdev/blockdev_3_3/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_0/mod.rs (11)
new(31-37)register(39-50)Devnode(63-65)HardwareInfo(69-77)UserInfo(81-83)InitializationTime(87-89)Pool(93-95)Uuid(99-101)Tier(105-107)PhysicalPath(111-119)TotalPhysicalSize(123-131)
src/dbus/blockdev/blockdev_3_7/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/types.rs (1)
new(290-295)
src/dbus/blockdev/blockdev_3_4/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/types.rs (1)
new(290-295)
src/dbus/blockdev/blockdev_3_6/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/types.rs (1)
new(290-295)
src/dbus/blockdev/blockdev_3_5/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/types.rs (1)
new(290-295)
src/dbus/blockdev/mod.rs (13)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/pool/mod.rs (1)
pool(53-53)src/engine/strat_engine/metadata/bda.rs (1)
dev_uuid(125-127)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(35-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(39-50)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(37-48)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(37-48)
src/dbus/blockdev/blockdev_3_2/mod.rs (5)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (9)
devnode_prop(12-14)hardware_info_prop(16-18)init_time_prop(20-22)physical_path_prop(24-26)pool_prop(28-30)tier_prop(36-38)total_physical_size_prop(32-34)user_info_prop(40-43)uuid_prop(45-48)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/mod.rs (4)
new(31-37)Pool(93-95)Uuid(99-101)Tier(105-107)src/dbus/types.rs (1)
new(290-295)
src/dbus/types.rs (1)
src/dbus/util.rs (1)
result_option_to_tuple(53-66)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (31)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile fmt-ci, 1.91.0, rustfmt)
- GitHub Check: checks (make -f Makefile check-typos, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: python-based-tests
- GitHub Check: checks-with-ci-repo
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
🔇 Additional comments (15)
src/dbus/blockdev/blockdev_3_1/mod.rs (1)
20-127: BlockdevR1 interface cleanly mirrors existing blockdev patternsThe struct shape,
register()implementation, and all property/method bindings reuse the shared helpers consistently with the R0/R2+ variants. I don’t see any behavioral or API-shape issues here; this looks ready to go.src/dbus/blockdev/blockdev_3_4/mod.rs (2)
22-35: LGTM!The struct definition and constructor follow the established pattern across BlockdevR* implementations.
37-48: LGTM!The registration pattern correctly delegates to the connection's object server and handles errors appropriately.
src/dbus/pool/mod.rs (2)
1-24: LGTM!Module structure and imports are appropriate for the pool registration functionality.
70-84: LGTM!The unregister flow correctly removes the D-Bus object, looks up the UUID, and cleans up the manager state.
src/dbus/blockdev/blockdev_3_7/mod.rs (1)
1-152: Implementation is consistent with other BlockdevR versions.*BlockdevR7 follows the same pattern as R4, R5, and R6. The structure, registration, and property delegation are all correct. The same optional refactoring suggestions apply: consider consolidating the duplicated code across versions and addressing the commented-out
set_UserInfomethod.src/dbus/types.rs (5)
14-31: LGTM!The type definitions provide clear version-specific wrappers and appropriate enums for D-Bus marshalling.
33-116: LGTM!The
LockedPoolsInfomarshalling handles complex nested structures appropriately, with proper error logging for conversion failures while allowing partial success.
118-220: LGTM!The shared helper function cleanly handles both R2 and R8 cases with a metadata flag, avoiding duplication while maintaining proper error handling.
222-276: LGTM!The wrapper pattern cleanly differentiates R2 and R8 behavior while sharing the underlying marshalling logic.
278-296: LGTM!The
Basicimplementation forPoolUuidand theParentPoolstruct provide the necessary type infrastructure for cross-module D-Bus coordination.src/dbus/blockdev/blockdev_3_2/mod.rs (1)
1-128: LGTM!BlockdevR2 represents an earlier interface version with
SetUserInfoimplemented and withoutNewPhysicalSize. The implementation is consistent and correct for its version level.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
1-132: LGTM!BlockdevR0 provides the foundational interface and correctly re-exports property helpers used across all versions. The implementation is clean and previous concerns have been addressed.
src/dbus/blockdev/blockdev_3_6/mod.rs (1)
1-152: Implementation is consistent with other BlockdevR versions.*BlockdevR6 follows the same pattern as R4, R5, and R7. The implementation is correct, and the same optional refactoring suggestions apply regarding code duplication and the commented-out
set_UserInfomethod.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
1-152: Implementation is consistent with other BlockdevR versions.*BlockdevR5 follows the same pattern as R4, R6, and R7. The implementation is correct, and the same optional refactoring suggestions apply regarding code duplication and the commented-out
set_UserInfomethod.
mulkieran
force-pushed
the
blockdev-changes
branch
from
d9179ec to
52a899b
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
src/dbus/pool/mod.rs (2)
52-61: Consider the impact of partial blockdev registration and pool lock lifetime.Two concerns:
Partial registration (duplicate concern): When
register_blockdevfails for individual devices, the function logs a warning and continues, ultimately returning success with an incomplete list of blockdev paths. This results in a pool being exposed on D-Bus with some blockdevs missing, creating an inconsistent view. Consider whether the caller should be notified of partial registration or if the behavior should be documented.Pool lock: After calling
pool.blockdevs()on line 53, the pool reference remains in scope during the entire blockdev registration loop (lines 54-61). If the pool holds internal locks, this could block concurrent operations. Consider explicitly dropping the pool before the loop:let mut bd_paths = Vec::new(); let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); + drop(pool); for dev_uuid in bd_uuids {
64-66: Must unregister PoolR9 before returning error.The PoolR9 object is registered on D-Bus at lines 38-46, but when
engine.get_pool()returnsNone, this error path returns without unregistering the object. This leaves an orphaned D-Bus object in the connection's object server, corrupting the D-Bus view and making manager mappings inconsistent.Apply this diff to unregister the object before returning:
None => { + let _ = PoolR9::unregister(connection, path.clone()).await; Err(StratisError::Msg(format!("Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus"))) }Note: This issue was previously flagged and marked as "Addressed" but the fix is not present in the current code.
src/dbus/blockdev/shared.rs (1)
24-27: Eliminate theexpect()panic path and fix the error message.
get_mut_blockdev()can return an error. Usingexpect("FIXME")will crash stratisd instead of surfacing a D-Bus failure. Additionally, the error message incorrectly references "filesystem" instead of "block device".let (tier, bd) = guard .get_mut_blockdev(bd_uuid) - .expect("FIXME") - .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .map_err(|e| Error::Failed(format!("Failed to access block device {bd_uuid}: {e}")))? + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;src/dbus/blockdev/blockdev_3_2/mod.rs (1)
71-99: Sharedblockdev_properror message still mentions “filesystem”Because
Devnode,HardwareInfo,UserInfo,InitializationTime, etc. all delegate throughblockdev_prop, D‑Bus errors for a missing block device will currently say “No filesystem associated with UUID {bd_uuid}” (persrc/dbus/blockdev/shared.rs). That’s potentially confusing for blockdev callers; renaming it to reference “block device” would make the diagnostics clearer and more accurate.
🧹 Nitpick comments (6)
src/dbus/blockdev/blockdev_3_3/props.rs (1)
17-20: Stub noted for future implementation.The
set_user_info_propis correctly marked with#[allow(dead_code)]and has a FIXME comment. This is acceptable as a placeholder for future setter support.Would you like me to help implement this setter when you're ready to address the FIXME?
src/dbus/blockdev/blockdev_3_0/props.rs (1)
21-23: Potential truncation for pre-epoch timestamps.Casting
timestamp()(which returnsi64) tou64will produce incorrect values if the initialization time is somehow before Unix epoch (1970). While this is unlikely for block device initialization times, consider usingtimestamp() as u64only after validating non-negativity, or document the assumption.src/dbus/blockdev/blockdev_3_1/mod.rs (1)
131-141: Missingemits_changed_signalattribute.
TotalPhysicalSizeis the only property without an explicitemits_changed_signalattribute. Other properties consistently specify this (e.g.,"const"for immutable values,"false"for mutable ones). This defaults to"true"which may or may not be the intended behavior.Consider adding the appropriate signal emission behavior for consistency:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn TotalPhysicalSize(&self) -> Result<String, Error> {src/dbus/blockdev/blockdev_3_8/mod.rs (1)
90-104: Offer: Address the commented-outset_UserInfosetter.This FIXME placeholder appears across multiple BlockdevRX versions. If you'd like, I can help implement the setter logic or open an issue to track this work.
src/dbus/blockdev/blockdev_3_9/mod.rs (1)
1-165: Consider: Macro-based generation for BlockdevRX variants.All BlockdevRX implementations (R0-R9) follow an identical structure with only the interface version number differing. A declarative macro could generate these implementations, reducing boilerplate and ensuring consistency:
// Example macro sketch (in a shared module) macro_rules! impl_blockdev_interface { ($name:ident, $version:literal) => { pub struct $name { /* ... */ } impl $name { /* new, register */ } #[interface(name = concat!("org.storage.stratis3.blockdev.", $version))] impl $name { /* properties */ } }; } impl_blockdev_interface!(BlockdevR9, "r9");This is optional given the current approach is explicit and works correctly.
src/dbus/blockdev/blockdev_3_5/mod.rs (1)
84-88: Confirmemits_changed_signalsemantics forUserInfo/NewPhysicalSizeon R5Here
UserInfo(andNewPhysicalSize) use the default#[zbus(property)]annotation, whereas earlier versions (e.g., R0/R2) explicitly markUserInfowithemits_changed_signal = "false". If the 3.5 D‑Bus contract wasn’t meant to change in this respect, it may be safer to align these annotations with the earlier revisions so clients don’t see inconsistent introspection metadata across versions. If 3.5 is intentionally different, a brief comment explaining the divergence could help future maintainers.Also applies to: 142-164
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/dbus/blockdev/mod.rs
- src/dbus/blockdev/blockdev_3_6/mod.rs
- src/dbus/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/shared.rssrc/dbus/pool/mod.rssrc/dbus/blockdev/blockdev_3_0/props.rssrc/dbus/blockdev/blockdev_3_0/mod.rs
🧬 Code graph analysis (9)
src/dbus/blockdev/blockdev_3_3/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/shared.rs (11)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(123-125)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(120-122)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)
src/dbus/pool/mod.rs (3)
src/dbus/blockdev/mod.rs (1)
register_blockdev(43-148)src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/pool/pool_3_9/mod.rs (5)
connection(73-73)register(49-67)Uuid(98-100)new(33-47)unregister(69-75)
src/dbus/blockdev/blockdev_3_0/methods.rs (11)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(123-125)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(120-122)src/dbus/pool/mod.rs (1)
pool(53-53)
src/dbus/blockdev/blockdev_3_9/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_1/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_2/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(34-50)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (28)
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks (make -f Makefile check-typos, 1.91.0, cargo)
🔇 Additional comments (20)
src/dbus/pool/mod.rs (2)
1-24: LGTM!The imports, module declarations, and re-exports are well-structured and appropriate for the pool registration functionality.
70-84: LGTM!The unregistration flow is correctly ordered: it first unregisters the D-Bus object (line 75), then removes the pool from the manager state (lines 77-81). This ensures that if the D-Bus unregistration fails, the manager state remains consistent.
src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-15: LGTM!The
new_physical_size_propfunction correctly maps the optionalnew_sizefrom the block device to a D-Bus-compatible tuple representation usingoption_to_tuple.src/dbus/blockdev/blockdev_3_0/props.rs (2)
29-41: Proper error handling for missing pool paths.This correctly returns an error when the pool object path cannot be found, rather than returning a default placeholder path. This addresses the D-Bus contract requirements.
51-54: FIXME: Consider lazy evaluation.The comment notes that
option_to_tuplecould be made lazy. This is a minor optimization opportunity where the defaultString::new()allocation could be avoided when the option has a value.src/dbus/blockdev/blockdev_3_1/mod.rs (1)
48-60: LGTM!The
registerfunction correctly constructs theBlockdevR1instance and registers it on the D-Bus object server. Error propagation is handled via?.src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: LGTM!The
set_user_info_methodimplementation is well-structured:
- Properly handles the async pool lookup with appropriate error conversion
- Covers all
RenameActionvariants (NoSource,Renamed,Identity)- Uses consistent error codes (
DbusErrorEnum::ERROR/OK) and response formatting- The default return value using
DevUuid::nil()appropriately signals no change occurredsrc/dbus/blockdev/blockdev_3_8/mod.rs (2)
27-62: LGTM: BlockdevR8 struct and registration logic are well-structured.The struct properly stores all required context (engine, manager, parent_uuid, uuid) and the
registerfunction correctly instantiates and registers the object with the D-Bus object server.
64-165: LGTM: D-Bus interface implementation is correct.Property methods properly delegate to the shared
blockdev_prophelpers with appropriate signal emission settings (const,false, or default). The interface name matches the expected version (r8).src/dbus/blockdev/blockdev_3_4/mod.rs (2)
27-62: LGTM: BlockdevR4 struct and registration follow the established pattern.
64-165: LGTM: D-Bus interface correctly implements org.storage.stratis3.blockdev.r4.Property implementations correctly delegate to shared helpers with appropriate emission settings.
src/dbus/blockdev/blockdev_3_7/mod.rs (2)
28-63: LGTM: BlockdevR7 struct and registration logic are correct.
65-166: LGTM: D-Bus interface correctly implements org.storage.stratis3.blockdev.r7.src/dbus/blockdev/blockdev_3_3/mod.rs (3)
26-28: LGTM: Properly declares and re-exportsnew_physical_size_prop.This module serves as the source for
new_physical_size_propwhich is correctly re-exported for use by other BlockdevRX versions (R4, R7, R8, R9).
30-65: LGTM: BlockdevR3 struct and registration logic are well-structured.
67-168: LGTM: D-Bus interface correctly implements org.storage.stratis3.blockdev.r3.src/dbus/blockdev/blockdev_3_9/mod.rs (2)
27-62: LGTM: BlockdevR9 struct and registration logic are correct.
64-165: LGTM: D-Bus interface correctly implements org.storage.stratis3.blockdev.r9.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
30-145: BlockdevR0 registration and property wiring look consistent and correctThe struct layout,
registerhelper, and D‑Bus interface implementation all line up cleanly with the shared helpers (blockdev_prop,pool_prop,set_user_info_method). Ownership viaArc/Lockableand the use ofOwnedObjectPathforPoolare appropriate; I don’t see functional or concurrency issues in this module.src/dbus/blockdev/blockdev_3_2/mod.rs (1)
26-61: R2 interface and registration mirror R0 cleanly
BlockdevR2’s constructor,registerhelper,SetUserInfowiring, and property implementations all consistently reuse the shared helpers fromblockdev_3_0/shared.rs. The use ofOwnedObjectPathforPoolandDevUuidforUuidmatches the props signatures and looks sound; I don’t see functional issues in this module.Also applies to: 63-142
mulkieran
force-pushed
the
blockdev-changes
branch
from
52a899b to
f3c7d91
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (4)
src/dbus/blockdev/shared.rs (2)
24-29: Fix the incorrect error message.The error message at line 28 references "filesystem" but this function operates on block devices. This should say "No block device associated with UUID" for accurate debugging.
.and_then(|v| { - v.ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}"))) + v.ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}"))) })?;
47-49: Fix the incorrect error message.The error message references "filesystem" but this function operates on block devices. This should say "No block device associated with UUID" for consistency and accurate debugging.
let (tier, bd) = guard .get_blockdev(bd_uuid) - .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;src/dbus/blockdev/mod.rs (1)
56-146: Roll back partial registrations on error.If any
BlockdevRX::registercall fails mid-sequence, previously registered interfaces remain on the D-Bus object server without corresponding manager mappings. This creates orphaned D-Bus objects.Consider wrapping the registration sequence to clean up on failure:
if let Err(e) = async { BlockdevR0::register(...).await?; BlockdevR1::register(...).await?; // ... all others Ok::<_, StratisError>(()) }.await { let _ = connection.object_server().remove::<BlockdevR0, _>(&path).await; let _ = connection.object_server().remove::<BlockdevR1, _>(&path).await; // ... cleanup all return Err(e); }src/dbus/pool/mod.rs (1)
33-67: Unregister PoolR9 onget_poolfailure and droppoolbefore async blockdev registrationRight now the flow is:
- You successfully call
PoolR9::register(...)forpath.- Then you call
engine.get_pool(...). If this returnsNone, you immediately return anErr(Line 64–66) but never undo the registration.That leaves a PoolR9 object pinned in the connection’s object server for a pool we consider “gone”, which makes the D‑Bus view inconsistent with the engine/manager state.
Additionally, in the
Some(pool)branch you buildbd_uuidsfrompool.blockdevs()and then await inside thefor dev_uuid in bd_uuidsloop; unlesspoolis trivially cheap, it’s safer to drop it before entering the async loop to avoid holding any underlying guards/locks across.await.A concrete fix would look like:
@@ - PoolR9::register( + PoolR9::register( engine, connection, manager, counter, path.clone(), pool_uuid, ) .await?; - match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { - Some(pool) => { - manager.write().await.add_pool(&path, pool_uuid); - - let mut bd_paths = Vec::new(); - let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); - for dev_uuid in bd_uuids { + let pool = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { + Some(pool) => pool, + None => { + // Tear down the D‑Bus object we just registered before surfacing the error. + let _ = PoolR9::unregister(connection, path.clone()).await; + return Err(StratisError::Msg(format!( + "Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus" + ))); + } + }; + + manager.write().await.add_pool(&path, pool_uuid); + + let mut bd_paths = Vec::new(); + let bd_uuids = pool.blockdevs().into_iter().map(|(u, _, _)| u).collect::<Vec<_>>(); + drop(pool); + for dev_uuid in bd_uuids { match register_blockdev(engine, connection, manager, counter, pool_uuid, dev_uuid).await { Ok(op) => bd_paths.push(op), Err(_) => { warn!("Unable to register object path for blockdev with UUID {dev_uuid} belonging to pool {pool_uuid} on the D-Bus"); }, } - } - None => { - Err(StratisError::Msg(format!("Pool with {pool_uuid} was successfully started but appears to have been removed before it could be exposed on the D-Bus"))) - } - } + } + Ok((path, bd_paths))This keeps the D‑Bus and manager/engine views aligned even on failure and avoids holding
poolacross async registration of blockdevs.
🧹 Nitpick comments (2)
src/dbus/blockdev/blockdev_3_1/mod.rs (1)
131-141: Inconsistentemits_changed_signalannotation.
TotalPhysicalSizeuses#[zbus(property)]without an explicitemits_changed_signalspecification, while all other properties explicitly declare their signal behavior. This may result in the default behavior (typically"true"), which might not be the intended semantics for a property that can change when the block device is resized.Consider adding an explicit annotation for consistency and correctness:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))]src/dbus/blockdev/blockdev_3_6/mod.rs (1)
85-89: Add explicitemits_changed_signalvalues toUserInfoandNewPhysicalSizeThe web search confirms that zbus defaults to
emits_changed_signal = "true"when the annotation is omitted, which appears in D-Bus introspection asorg.freedesktop.DBus.Property.EmitsChangedSignal="true".In this file, most properties explicitly set
emits_changed_signalto either"const"(Devnode, HardwareInfo, InitializationTime, Pool, Uuid, PhysicalPath) or"false"(Tier). However,UserInfoandNewPhysicalSizeomit this value, causing them to default to"true"and emit change signals, which is inconsistent with the majority of other properties in the interface.For D-Bus contract clarity and consistency, explicitly set
emits_changed_signalfor both properties (e.g.,"false"if they should not emit signals, or"const"if appropriate).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/dbus/blockdev/blockdev_3_3/props.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/mod.rssrc/dbus/blockdev/shared.rssrc/dbus/pool/mod.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/blockdev/blockdev_3_0/props.rs
🧬 Code graph analysis (12)
src/dbus/blockdev/blockdev_3_1/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(49-61)
src/dbus/blockdev/shared.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(123-125)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(120-122)
src/dbus/blockdev/blockdev_3_2/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/dbus/mod.rs (10)
src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/pool/pool_3_9/mod.rs (2)
connection(73-73)new(33-47)src/dbus/blockdev/mod.rs (1)
register_blockdev(43-148)src/stratis/keys.rs (1)
engine(28-46)src/dbus/pool/mod.rs (1)
pool(53-53)src/dbus/manager/manager_3_9/mod.rs (1)
new(47-59)src/dbus/manager/manager_3_0/mod.rs (1)
new(39-51)src/engine/types/mod.rs (4)
new(178-180)new(277-279)new(310-322)new(375-377)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/dbus/blockdev/blockdev_3_8/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_0/methods.rs (13)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(123-125)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(120-122)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)src/dbus/pool/mod.rs (1)
pool(53-53)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (5)
devnode_prop(13-15)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_5/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_3/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: stratis-cli-checks
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks-with-ci-repo
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
🔇 Additional comments (17)
src/dbus/blockdev/blockdev_3_1/mod.rs (2)
1-61: LGTM on struct definition and registration.The
BlockdevR1struct andregistermethod follow the established pattern from otherBlockdevRXvariants, correctly cloning the manager handle and registering the instance on the D-Bus object server.
63-117: Interface methods and properties are correctly implemented.The
SetUserInfomethod and property getters delegate appropriately to the shared helpers and reuse code fromblockdev_3_0. Theemits_changed_signalannotations are consistent with the expected mutability characteristics of each property.src/dbus/blockdev/shared.rs (1)
11-34:set_blockdev_propis marked#[allow(dead_code)]— verify intended usage.The function is allowed as dead code, suggesting it may be reserved for future use. Confirm this is intentional and consider adding a brief doc comment explaining its purpose or removing it if not needed.
src/dbus/blockdev/mod.rs (1)
43-55: LGTM on path generation.The atomic counter with
Ordering::AcqRelcorrectly ensures unique path generation across concurrent registrations.src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: LGTM!The
set_user_info_methodcorrectly handles allRenameActionoutcomes, uses appropriate error codes, and follows the established D-Bus method return pattern for stratisd.src/dbus/mod.rs (2)
34-55: LGTM!The
create_dbus_handlerfunction correctly initializes the D-Bus subsystem with properArcsharing of the connection, counter, and manager. The error propagation via?ensures failures at any step bubble up appropriately.
10-15: Public API surface is well-organized.The re-exports provide a clean public interface for external consumers of the D-Bus module, exposing only the necessary types and registration functions.
src/dbus/blockdev/blockdev_3_8/mod.rs (1)
27-165: BlockdevR8 D‑Bus surface looks consistent and correctly wiredThe struct fields,
registerhelper, and all property accessors cleanly delegate to the shared helpers (blockdev_prop,pool_prop,new_physical_size_prop) and match the established pattern from the other blockdev R* interfaces. I don’t see correctness or lifetime issues here.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
27-165: BlockdevR4 implementation mirrors other versions cleanly
BlockdevR4’s struct,registerhelper, and property methods are a straightforward clone of the proven pattern (viablockdev_prop,pool_prop,new_physical_size_prop). I don’t see any functional or lifetime issues here.src/dbus/blockdev/blockdev_3_9/mod.rs (1)
27-165: BlockdevR9 D‑Bus surface is consistent with prior R variants*The
BlockdevR9struct,registerfunction, and property accessors are wired exactly like the earlier revisions, delegating to the shared helpers and manager without introducing new edge cases. Looks good.src/dbus/blockdev/blockdev_3_3/mod.rs (1)
26-168: BlockdevR3 +new_physical_size_propre-export look correctThe R3 module cleanly introduces its
propssubmodule, re‑exportsnew_physical_size_prop, and wires all properties via the shared helpers (blockdev_prop,pool_prop). Theregisterhelper and interface definition follow the same, already‑validated pattern; no issues spotted.src/dbus/blockdev/blockdev_3_7/mod.rs (1)
28-165: BlockdevR7 follows the shared blockdev property pattern
BlockdevR7correctly reuses the common property helpers andnew_physical_size_prop, and itsregistermethod mirrors the other versions. I don’t see any functional problems here.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
30-146: Baseline BlockdevR0 interface and helpers look solid
BlockdevR0cleanly wrapsset_user_info_methodand routes all properties through the shared helpers (blockdev_prop,pool_prop, etc.), matching the pattern reused by the higher‑revision interfaces. I don’t see any correctness or concurrency issues in this module.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
27-165: BlockdevR5 implementation is consistent and reuse-focusedThe
BlockdevR5struct/registercombo and its D‑Bus properties all delegate to the shared helpers andnew_physical_size_prop, in line with the other R* implementations. No issues stand out.src/dbus/blockdev/blockdev_3_2/mod.rs (1)
26-141: BlockdevR2 registration and property wiring look correctStruct fields, constructor,
register,SetUserInfo, and all properties are consistently wired through the shared helpers (blockdev_prop,pool_prop,set_user_info_method) and match the established blockdev patterns. I don't see any functional or API-surface issues here.src/dbus/blockdev/blockdev_3_6/mod.rs (1)
28-63: BlockdevR6 object construction and shared-property usage look solid
BlockdevR6mirrors the R2 pattern,registercleanly binds the interface on the connection, and all read-side properties are correctly delegated to the shared helpers (blockdev_prop,pool_prop,new_physical_size_prop). No obvious correctness or API issues here.Also applies to: 65-83, 107-153
src/dbus/blockdev/blockdev_3_0/props.rs (1)
13-54: Shared blockdev_3_0 property helpers andpool_propare well-structuredThe property helpers are simple, side-effect-free views over
BlockDev, andpool_propnow correctly looks up and clones the real pool object path viapool_get_path, returning a descriptiveError::Failedwhen missing. This aligns with how later blockdev surfaces consume these helpers and avoids the earlier issue of returning the default/path.
mulkieran
force-pushed
the
blockdev-changes
branch
from
f3c7d91 to
3b6873f
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
src/dbus/blockdev/shared.rs (2)
47-49: Fix the incorrect error message.The error message references "filesystem" but this function operates on block devices. This should say "No block device associated with UUID" for consistency and accurate debugging.
Apply this diff:
let (tier, bd) = guard .get_blockdev(bd_uuid) - .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;
24-29: Fix the incorrect error message.Line 28 references "filesystem" but this function operates on block devices. The error message should say "No block device associated with UUID" for consistency and accurate debugging.
Apply this diff:
let (tier, bd) = guard .get_mut_blockdev(bd_uuid) .map_err(|e| Error::Failed(e.to_string())) .and_then(|v| { - v.ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}"))) + v.ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}"))) })?;src/dbus/blockdev/mod.rs (1)
43-148: Roll back partial registrations on error.If any
BlockdevRX::registercall fails mid-sequence, previously registered interfaces remain on the D-Bus object server while the manager is never updated, creating orphaned D-Bus objects. Consider wrapping the registration sequence in error handling that removes previously registered interfaces if a later registration fails.
🧹 Nitpick comments (3)
src/dbus/blockdev/blockdev_3_3/props.rs (1)
17-20: Track the set_UserInfo implementation.This is a no-op stub marked FIXME. Ensure this placeholder is addressed before the property setter is exposed in the D-Bus interface.
Do you want me to open a tracking issue for implementing the
set_user_info_propfunctionality, or is this already planned for a follow-up?src/dbus/blockdev/blockdev_3_8/mod.rs (1)
64-165: LGTM, but note the FIXME for set_UserInfo.The D-Bus interface properties are correctly implemented. The commented-out
set_UserInfoproperty setter (lines 90-104) is marked FIXME and should be tracked for future implementation.Do you want me to open a tracking issue for implementing the
set_UserInfoproperty setter across all blockdev versions?src/dbus/blockdev/blockdev_3_3/mod.rs (1)
30-168: LGTM! Consistent BlockdevR3 implementation.The D-Bus interface implementation follows the established pattern across all blockdev versions. Property delegation to shared helpers is correct, and the new
NewPhysicalSizeproperty is properly wired.Regarding the commented-out
set_UserInfoproperty setter (lines 93-107): If you'd like to implement this, I can help generate the requiredset_blockdev_prophelper or open an issue to track it.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/dbus/blockdev/blockdev_3_9/mod.rs
- src/dbus/pool/mod.rs
- src/dbus/blockdev/blockdev_3_2/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/shared.rssrc/dbus/blockdev/mod.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/blockdev/blockdev_3_0/props.rs
🧬 Code graph analysis (11)
src/dbus/blockdev/blockdev_3_1/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_3/mod.rs (6)
new(38-50)Devnode(71-73)HardwareInfo(77-85)Pool(117-119)Uuid(123-125)Tier(129-131)
src/dbus/blockdev/blockdev_3_8/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (5)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/shared.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(109-111)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(123-125)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(121-123)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(120-122)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(120-122)
src/dbus/blockdev/mod.rs (13)
src/stratis/keys.rs (1)
engine(28-46)src/engine/strat_engine/metadata/bda.rs (1)
dev_uuid(125-127)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(49-61)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_0/methods.rs (2)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(113-115)src/dbus/pool/mod.rs (1)
pool(53-53)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/mod.rs (2)
src/dbus/manager/mod.rs (1)
register_manager(123-144)src/dbus/udev.rs (1)
new(25-39)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(36-52)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_0/props.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
new(35-47)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
🔇 Additional comments (13)
src/dbus/mod.rs (1)
34-55: LGTM!The
create_dbus_handlerfunction correctly orchestrates D-Bus setup: creates shared state, builds the connection with the Stratis service name, registers all manager interfaces, and returns the wired components for the caller.src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-15: LGTM!The
new_physical_size_propcorrectly retrieves the new size from the block device and formats it as a D-Bus-compatible tuple.src/dbus/blockdev/blockdev_3_1/mod.rs (2)
26-61: LGTM!The
BlockdevR1struct and registration logic follow the established pattern used across other blockdev versions, correctly wiring the engine, manager, and UUIDs.
63-142: LGTM!The D-Bus interface properties and methods are correctly implemented, delegating to shared property helpers and maintaining consistency with the blockdev interface contract.
src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: LGTM!The
set_user_info_methodcorrectly handles the full workflow: pool lookup, user info update via the engine, and mapping ofRenameActionoutcomes to D-Bus response tuples with appropriate status codes.src/dbus/blockdev/blockdev_3_8/mod.rs (1)
27-62: LGTM!The
BlockdevR8struct and registration logic follow the established pattern, correctly integrating with the engine, manager, and D-Bus connection.src/dbus/blockdev/blockdev_3_4/mod.rs (2)
27-62: LGTM!The
BlockdevR4struct and registration method follow the established pattern used across blockdev versions, correctly wiring the necessary components.
64-165: LGTM, but note the FIXME for set_UserInfo.The D-Bus interface properties are correctly implemented using shared helpers. The commented-out
set_UserInfoproperty setter (lines 90-104) with FIXME should be tracked for future implementation.src/dbus/blockdev/blockdev_3_7/mod.rs (1)
28-166: LGTM! BlockdevR7 implementation is consistent.The implementation correctly follows the established pattern and properly imports
new_physical_size_propfrom the blockdev_3_3 module. All property delegations are correct.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
30-146: LGTM! BlockdevR0 implementation is solid.The base blockdev interface is well-structured. The
SetUserInfomethod (lines 69-73) correctly delegates toset_user_info_methodand returns the appropriate status tuple. All property implementations properly delegate to shared helpers.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
27-165: LGTM! BlockdevR5 follows the established pattern.Property implementations are correct and consistent with other versions. All delegations to shared helpers work properly.
src/dbus/blockdev/blockdev_3_6/mod.rs (1)
28-166: LGTM! BlockdevR6 implementation is consistent.All property implementations correctly delegate to shared helpers. The interface follows the established pattern.
src/dbus/blockdev/blockdev_3_0/props.rs (1)
13-53: LGTM! Property helper functions are well-implemented.All property accessors correctly delegate to the underlying
BlockDevtrait methods with appropriate transformations. Thepool_propimplementation (lines 29-41) properly retrieves the pool path from the Manager and provides a clear error message when the path is not found.
mulkieran
force-pushed
the
blockdev-changes
branch
from
3b6873f to
ebc91de
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/dbus/blockdev/shared.rs (1)
49-51: Fix the incorrect error message.The error message references "filesystem" but this function operates on block devices. This was previously flagged and should be corrected.
let (tier, bd) = guard .get_blockdev(bd_uuid) - .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;
🧹 Nitpick comments (15)
src/dbus/blockdev/blockdev_3_3/props.rs (1)
17-20: Address the FIXME placeholder.This is a stub function with a
FIXMEcomment. The#[allow(dead_code)]attribute confirms it's not yet wired into the D-Bus surface.Would you like me to help implement the
set_user_info_propfunction, or should I open an issue to track this task?src/dbus/blockdev/blockdev_3_1/mod.rs (1)
135-145: Consider addingemits_changed_signalannotation for consistency.The
TotalPhysicalSizeproperty uses#[zbus(property)]without an explicitemits_changed_signalvalue, unlike other properties in this interface (e.g.,Devnode,PhysicalPathuse"const",UserInfoandTieruse"false"). If the size can change at runtime,"false"would be appropriate; if it's constant,"const"would be more accurate.- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn TotalPhysicalSize(&self) -> Result<String, Error> {src/dbus/blockdev/blockdev_3_8/mod.rs (2)
106-114: Consider simplifying the nested Result unwrapping.The nested match can be simplified using
and_then:#[zbus(property(emits_changed_signal = "const"))] #[allow(non_snake_case)] async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await + .and_then(|r| r) }
90-104: Track theset_UserInfoplaceholder for future implementation.The commented-out setter appears across all BlockdevRN versions. Consider creating an issue to track this pending implementation.
Would you like me to open an issue to track the
set_UserInfoimplementation across all blockdev versions?src/dbus/blockdev/blockdev_3_4/mod.rs (1)
106-114: Same simplification opportunity as other versions.The nested match for
InitializationTimecould use.and_then(|r| r)as suggested for BlockdevR8.src/dbus/blockdev/blockdev_3_9/mod.rs (1)
106-114: Same nested match pattern as other versions.Consider applying the
.and_then(|r| r)simplification consistently across all BlockdevRN implementations.src/dbus/blockdev/blockdev_3_3/mod.rs (1)
109-117: SameInitializationTimesimplification opportunity.This nested match pattern appears across all BlockdevRN versions. Consider applying the
.and_then(|r| r)refactor consistently.src/dbus/blockdev/blockdev_3_7/mod.rs (2)
109-115: Consider flattening the nested Result pattern.The nested
matchwithOk(Err(r)),Err(r), andOk(Ok(r))works but is verbose. Sinceinit_time_propreturnsResult<u64, Error>andblockdev_propwraps it, you could simplify withand_thenor a helper:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }Note: This pattern appears in all BlockdevR* implementations—if simplified, consider updating them all for consistency.
91-105: Track or remove the commentedset_UserInfoFIXME.The commented-out
set_UserInfoproperty setter has been present since R5. If this feature is planned, consider opening an issue to track it; otherwise, remove the commented code to reduce maintenance noise.Do you want me to help draft an issue or verify if this is already tracked?
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
101-107: Consider flattening the nested Result pattern.The nested
matchwithOk(Err(r)),Err(r), andOk(Ok(r))works but is verbose:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }src/dbus/blockdev/blockdev_3_5/mod.rs (2)
108-114: Consider flattening the nested Result pattern.Same nested
matchpattern as in other versions:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }
90-104: Track or remove the commentedset_UserInfoFIXME.This commented property setter appears in R5, R6, and R7. Consider tracking this as a feature request or removing the placeholder.
src/dbus/blockdev/blockdev_3_2/mod.rs (1)
97-103: Consider flattening the nested Result pattern.Same nested
matchpattern:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }src/dbus/blockdev/blockdev_3_6/mod.rs (2)
109-115: Consider flattening the nested Result pattern.Same nested
matchpattern as in all other versions:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }
91-105: Track or remove the commentedset_UserInfoFIXME.This commented property setter appears across R5, R6, and R7. Consider tracking as a feature or removing to reduce clutter.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/dbus/pool/mod.rs
- src/dbus/blockdev/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/blockdev_3_0/props.rssrc/dbus/blockdev/shared.rssrc/dbus/blockdev/blockdev_3_0/mod.rs
🧬 Code graph analysis (11)
src/dbus/blockdev/blockdev_3_1/mod.rs (2)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/blockdev/blockdev_3_3/props.rs (2)
src/dbus/blockdev/blockdev_3_2/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
new(38-50)
src/dbus/blockdev/blockdev_3_0/props.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
new(35-47)
src/dbus/blockdev/blockdev_3_9/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_4/mod.rs (2)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)
src/dbus/blockdev/shared.rs (11)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(117-119)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(127-129)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(125-127)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(125-127)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(124-126)
src/dbus/mod.rs (4)
src/dbus/blockdev/mod.rs (1)
register_blockdev(43-148)src/dbus/manager/mod.rs (1)
register_manager(123-144)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/dbus/blockdev/blockdev_3_5/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/blockdev/blockdev_3_0/methods.rs (4)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(117-119)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)src/dbus/pool/mod.rs (1)
pool(53-53)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: python-based-tests
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: stratis-min-cli-checks
🔇 Additional comments (17)
src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: LGTM! Clean implementation of the D-Bus method.The function correctly handles all
RenameActionvariants with appropriate status codes and error messages. The pattern of using a default return value withDevUuid::nil()for unchanged cases aligns with D-Bus conventions for optional return data.src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-15: LGTM! Correct property accessor implementation.The
new_physical_size_propfunction properly converts the optionalnew_sizeto a D-Bus-compatible tuple usingoption_to_tuple.src/dbus/blockdev/shared.rs (1)
11-36: LGTM! Proper error handling for mutable access.The
set_blockdev_propfunction correctly propagates errors fromget_mut_blockdevusingmap_errand provides clear error messages for missing pool/block device.src/dbus/blockdev/blockdev_3_1/mod.rs (1)
26-61: LGTM! Well-structured D-Bus interface registration.The
BlockdevR1struct and itsregistermethod follow the established pattern from other blockdev versions, correctly wiring up the engine, manager, and connection.src/dbus/mod.rs (1)
34-55: LGTM! Clean D-Bus handler initialization.The
create_dbus_handlerfunction properly:
- Creates shared state (counter, manager) with appropriate synchronization primitives
- Establishes the D-Bus system connection with the Stratis service name
- Registers all manager interfaces before creating the UdevHandler
- Returns the necessary components for further D-Bus operations
The error propagation via
?ensures failures are surfaced to callers.src/dbus/blockdev/blockdev_3_8/mod.rs (1)
27-62: LGTM! BlockdevR8 struct and registration follow established patterns.The struct definition and
registerfunction correctly implement the D-Bus object registration, consistent with other BlockdevRN versions.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
27-62: LGTM! BlockdevR4 implementation is consistent with the R0-R9 family.The struct and registration logic correctly follow the established pattern.
src/dbus/blockdev/blockdev_3_9/mod.rs (1)
27-62: LGTM! BlockdevR9 correctly completes the R0-R9 interface family.The implementation maintains consistency with other versions.
src/dbus/blockdev/blockdev_3_0/props.rs (1)
13-53: LGTM! Property accessors are well-structured and reusable.The functions correctly implement the property access pattern with appropriate error handling. The
init_time_propproperly handles the potential u64 conversion failure for timestamps, andpool_propprovides a clear error message when the pool path is not found.src/dbus/blockdev/blockdev_3_3/mod.rs (2)
26-28: LGTM! Module organization correctly introducesnew_physical_size_prop.BlockdevR3 appropriately declares the
propsmodule and re-exportsnew_physical_size_propfor use by later versions (R4-R9).
30-65: BlockdevR3 struct and registration are consistent with the interface family.The implementation follows the established pattern.
src/dbus/blockdev/blockdev_3_7/mod.rs (1)
28-62: LGTM: Clean struct and registration pattern.The
BlockdevR7struct andregistermethod follow the established pattern for D-Bus blockdev interfaces, correctly wiring the engine, manager, and UUIDs through to the zbus object server.src/dbus/blockdev/blockdev_3_0/mod.rs (2)
30-64: LGTM: Well-structured BlockdevR0 foundation.The struct and registration logic are clean and correctly establish the base pattern for the R0 interface. The
SetUserInfomethod (lines 69-73) provides the mutable operation that later versions expose differently.
93-97: Note: UserInfo signal emission differs from R5/R6/R7.BlockdevR0 specifies
emits_changed_signal = "false"forUserInfo, while R5, R6, and R7 use the default emission behavior (which emits changes). If this is intentional API evolution, it's fine; otherwise, consider aligning the signal behavior across versions for consistency.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
27-61: LGTM: BlockdevR5 correctly extends the pattern.The struct and registration logic follow the established pattern and correctly integrate the
NewPhysicalSizeproperty introduced in this version.src/dbus/blockdev/blockdev_3_2/mod.rs (1)
26-60: LGTM: BlockdevR2 correctly follows the R0/R2 pattern.The struct and registration logic are consistent with R0, providing the
SetUserInfomethod and omittingNewPhysicalSizeas appropriate for this version.src/dbus/blockdev/blockdev_3_6/mod.rs (1)
28-62: LGTM: BlockdevR6 follows the established pattern correctly.The struct and registration logic cleanly implement the R6 interface with the expected property set.
mulkieran
force-pushed
the
blockdev-changes
branch
from
ebc91de to
63400e4
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
src/dbus/blockdev/shared.rs (1)
49-51: Fix the incorrect error message.The error message references "filesystem" but this function operates on block devices. This should say "No block device associated with UUID" for consistency and accurate debugging.
let (tier, bd) = guard .get_blockdev(bd_uuid) - .ok_or_else(|| Error::Failed(format!("No filesystem associated with UUID {bd_uuid}")))?; + .ok_or_else(|| Error::Failed(format!("No block device associated with UUID {bd_uuid}")))?;src/dbus/blockdev/mod.rs (1)
56-147: Roll back partial registrations on error.If any
BlockdevRX::registercall fails after previous registrations succeeded, the function returns immediately via?, leaving previously registered blockdev interfaces pinned in the D-Bus object server. TheManagerupdate on line 146 never executes, creating an inconsistent state where orphaned D-Bus objects exist without corresponding manager mappings.Consider wrapping the registration sequence in error handling that unregisters previously registered interfaces on failure, or document that partial registration failures are expected to be fatal for the daemon.
src/dbus/blockdev/blockdev_3_5/mod.rs (1)
84-88: Align UserInfo property emission behavior (same as R7).Same issue as in BlockdevR7: the
UserInfoproperty should explicitly setemits_changed_signal = "false"to match R0 and R2.Apply this diff:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn UserInfo(&self) -> Result<(bool, String), Error> {src/dbus/blockdev/blockdev_3_6/mod.rs (1)
85-89: Align UserInfo property emission behavior (same as R5/R7).Same issue as in BlockdevR5 and BlockdevR7: the
UserInfoproperty should explicitly setemits_changed_signal = "false"to match R0 and R2.Apply this diff:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn UserInfo(&self) -> Result<(bool, String), Error> {
🧹 Nitpick comments (6)
src/dbus/blockdev/blockdev_3_3/props.rs (1)
17-20: Address the FIXME placeholder.This function is marked with
#[allow(dead_code)]and contains aFIXMEcomment indicating incomplete implementation. If property setters are needed for the D-Bus interface, the implementation should be completed.Would you like me to help implement this setter or open an issue to track this task?
src/dbus/blockdev/blockdev_3_1/mod.rs (1)
97-103: Consider simplifying nested Result handling.The nested match can be simplified using
transpose()orflatten()for cleaner code:#[zbus(property(emits_changed_signal = "const"))] #[allow(non_snake_case)] async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await + .and_then(|r| r) }src/dbus/blockdev/blockdev_3_8/mod.rs (2)
90-104: Track the FIXME forset_UserInfoimplementation.The commented-out setter indicates incomplete functionality. Consider creating a tracking issue to ensure this doesn't get forgotten.
Would you like me to open a new issue to track the implementation of
set_UserInfoacross all BlockdevR* interfaces?
106-114: Consider simplifying nested Result handling.The current pattern works but could be more idiomatic using
and_thenor the?operator with a flattening approach:async fn InitializationTime(&self) -> Result<u64, Error> { - match blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop).await { - Ok(Err(r)) => Err(r), - Err(r) => Err(r), - Ok(Ok(r)) => Ok(r), - } + blockdev_prop(&self.engine, self.parent_uuid, self.uuid, init_time_prop) + .await? }This works because
init_time_propreturnsResult<u64, Error>, andblockdev_propwraps it in anotherResult. The?operator will propagate the outer error, and then the innerResultcan be returned directly.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
64-169: Consider macro-based code generation for BlockdevR interfaces.*BlockdevR4, R8, R9 (and likely R0-R7) share nearly identical implementations with only the interface name differing (
org.storage.stratis3.blockdev.r4vs.r8vs.r9). This duplication is error-prone when changes need to be applied across all versions.A declarative macro or build-time code generation could reduce maintenance burden:
// Example macro approach blockdev_interface!(BlockdevR4, "org.storage.stratis3.blockdev.r4"); blockdev_interface!(BlockdevR8, "org.storage.stratis3.blockdev.r8"); // etc.This is a low-priority refactor since the current approach works and provides explicit versioning.
src/dbus/blockdev/blockdev_3_7/mod.rs (1)
91-105: Track the FIXME for set_UserInfo implementation.The commented-out
set_UserInfosetter is marked with FIXME. If this functionality is planned for a future release, consider opening a tracking issue to ensure it doesn't get overlooked.Would you like me to help draft an issue description for implementing the UserInfo property setter across the relevant BlockdevR* interfaces?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/pool/mod.rssrc/dbus/blockdev/shared.rssrc/dbus/blockdev/mod.rssrc/dbus/blockdev/blockdev_3_0/props.rs
🧬 Code graph analysis (10)
src/dbus/blockdev/blockdev_3_0/methods.rs (13)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(117-119)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(113-115)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(127-129)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(125-127)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(125-127)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(124-126)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(124-126)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)src/dbus/pool/mod.rs (1)
pool(50-50)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/mod.rs (7)
src/dbus/util.rs (12)
connection(87-89)connection(100-102)connection(129-131)connection(138-140)connection(153-155)connection(162-164)connection(171-173)connection(180-182)connection(189-191)connection(198-200)connection(207-209)connection(216-218)src/dbus/manager/mod.rs (1)
register_manager(123-144)src/dbus/pool/mod.rs (1)
pool(50-50)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
new(38-50)src/dbus/manager/manager_3_0/mod.rs (1)
new(39-51)src/dbus/udev.rs (1)
new(25-39)src/engine/structures/lock.rs (1)
new_shared(84-86)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
register(48-60)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
register(52-64)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
register(50-62)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
register(49-61)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
register(49-61)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
src/dbus/blockdev/blockdev_3_1/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)
src/dbus/blockdev/blockdev_3_8/mod.rs (2)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/mod.rs (5)
new(38-50)register(52-64)Pool(111-113)Uuid(117-119)Tier(123-125)
src/dbus/blockdev/blockdev_3_0/props.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
new(34-46)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
new(38-50)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
new(36-48)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
new(35-47)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
new(35-47)
src/dbus/blockdev/blockdev_3_9/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)src/dbus/blockdev/blockdev_3_0/mod.rs (4)
new(38-50)Pool(111-113)Uuid(117-119)Tier(123-125)
src/dbus/blockdev/blockdev_3_4/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (1)
blockdev_prop(38-54)src/dbus/blockdev/blockdev_3_3/props.rs (1)
new_physical_size_prop(10-15)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
- GitHub Check: tests-with-testing-repo (master)
🔇 Additional comments (22)
src/dbus/blockdev/blockdev_3_0/methods.rs (1)
13-53: LGTM!The
set_user_info_methodimplementation correctly handles allRenameActionvariants and properly maps engine errors to D-Bus error responses. The use oftuple_to_optionfor converting D-Bus optional semantics is appropriate.src/dbus/blockdev/blockdev_3_3/props.rs (1)
10-15: LGTM!The property accessor correctly maps the optional
new_size()to a D-Bus tuple representation using theoption_to_tuplehelper.src/dbus/blockdev/shared.rs (1)
11-36: LGTM!The
set_blockdev_propfunction properly handles both the pool lookup error and the block device lookup error with appropriate error chaining usingmap_errandand_then.src/dbus/blockdev/blockdev_3_1/mod.rs (2)
135-145: Verify theemits_changed_signalannotation for TotalPhysicalSize.This property uses
#[zbus(property)]without an explicitemits_changed_signalattribute, while other properties in this interface explicitly specify"const"or"false". IfTotalPhysicalSizecan change (e.g., device resize),"false"would be appropriate; if it's immutable after initialization,"const"would be consistent with similar properties.
26-61: LGTM!The
BlockdevR1struct and itsregistermethod follow the established pattern fromBlockdevR0, correctly delegating to shared property helpers and the commonset_user_info_method.src/dbus/blockdev/mod.rs (1)
20-41: LGTM!The module structure cleanly organizes the versioned blockdev interfaces (R0-R9) with appropriate public re-exports for external consumption.
src/dbus/mod.rs (2)
1-33: LGTM: Module structure and imports are well-organized.The module declarations and public re-exports establish a clean API surface for the D-Bus subsystem.
34-55: Well-structured D-Bus handler initialization.The function correctly:
- Creates a shared counter for unique object path generation
- Initializes the Manager with
Lockable::new_shared- Builds the system D-Bus connection with the appropriate service name
- Registers manager interfaces before constructing UdevHandler
- Properly clones Arc references where needed
The use of
?for error propagation ensures that any failure during setup is properly bubbled up.src/dbus/blockdev/blockdev_3_8/mod.rs (1)
27-62: LGTM: Struct and registration follow the established pattern.The
BlockdevR8struct and itsregistermethod correctly mirror the pattern established inBlockdevR0(as shown in the relevant snippets), maintaining consistency across interface versions.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
27-62: LGTM: Consistent implementation pattern.The struct definition and registration logic correctly follow the established pattern for versioned blockdev interfaces.
src/dbus/pool/mod.rs (2)
26-65: LGTM: Pool registration flow is well-structured.The implementation correctly:
- Checks pool existence before any D-Bus registration
- Generates a unique path using the atomic counter
- Registers the pool, then adds to manager tracking
- Gracefully handles blockdev registration failures with warnings
The approach of continuing despite individual blockdev failures maximizes availability while logging issues for debugging.
67-81: Manager state inconsistency ifPoolR9::unregisterfails.If
PoolR9::unregisterreturns an error (line 72), the function returns early without removing the pool from the manager's tracking map. This leaves the manager with a stale entry pointing to a UUID for a path that may be in an inconsistent state.Consider whether the manager cleanup should happen regardless of unregister success:
pub async fn unregister_pool( manager: &Lockable<Arc<RwLock<Manager>>>, connection: &Arc<Connection>, path: &ObjectPath<'_>, ) -> StratisResult<PoolUuid> { - PoolR9::unregister(connection, path.clone()).await?; - let mut lock = manager.write().await; let uuid = lock .pool_get_uuid(path) .ok_or_else(|| StratisError::Msg(format!("No UUID associated with path {path}")))?; lock.remove_pool(path); + drop(lock); + + PoolR9::unregister(connection, path.clone()).await?; Ok(uuid) }Alternatively, if the current order is intentional (only remove from manager if D-Bus unregister succeeds), document this behavior.
src/dbus/blockdev/blockdev_3_9/mod.rs (2)
27-62: LGTM: BlockdevR9 struct and registration.Implementation correctly follows the established pattern for the latest blockdev interface version.
64-169: LGTM: D-Bus interface properties are correctly exposed.All property accessors properly delegate to shared helpers, and signal emission settings are appropriate:
constfor immutable properties (Devnode, HardwareInfo, InitializationTime, Pool, Uuid, PhysicalPath)falsefor Tier (can change but doesn't emit signals)- Default for mutable properties (UserInfo, TotalPhysicalSize, NewPhysicalSize)
src/dbus/blockdev/blockdev_3_3/mod.rs (2)
26-28: Good modular design for version-specific properties.Separating
new_physical_size_propinto apropsmodule and publicly re-exporting it allows later versions (R4, R8, R9) to import and reuse this property without duplication.
30-65: LGTM: BlockdevR3 correctly establishes the pattern for NewPhysicalSize.The struct and registration follow the established conventions, and this version appropriately introduces the
NewPhysicalSizeproperty that later versions inherit.src/dbus/blockdev/blockdev_3_0/props.rs (1)
13-53: LGTM! Clean property accessor implementation.The property accessor functions are well-structured and follow consistent patterns. The
pool_propfunction correctly retrieves the actual pool object path from the Manager, addressing previous review feedback. Error handling is appropriate throughout.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
30-150: LGTM! BlockdevR0 interface is correctly implemented.The D-Bus interface implementation is clean and follows the established pattern. Properties correctly delegate to the shared
blockdev_prophelper and individual prop functions. TheSetUserInfomethod properly delegates toset_user_info_method.src/dbus/blockdev/blockdev_3_7/mod.rs (1)
28-170: BlockdevR7 implementation follows established pattern.The interface structure and property delegation are consistent with other BlockdevR* variants. The addition of
NewPhysicalSizeproperty correctly reuses the helper from blockdev_3_3.src/dbus/blockdev/blockdev_3_5/mod.rs (1)
27-169: BlockdevR5 implementation is consistent.The interface follows the established pattern and correctly integrates property helpers from blockdev_3_0 and blockdev_3_3.
src/dbus/blockdev/blockdev_3_2/mod.rs (1)
26-146: LGTM! BlockdevR2 implementation is correct.The interface implementation is clean and consistent. The
UserInfoproperty correctly specifiesemits_changed_signal = "false", and theSetUserInfomethod properly delegates to the shared method helper.src/dbus/blockdev/blockdev_3_6/mod.rs (1)
28-170: BlockdevR6 implementation follows the pattern.The interface structure and property delegation are consistent with the established BlockdevR* pattern. The integration of shared property helpers is correct.
| #[zbus(property)] | ||
| #[allow(non_snake_case)] | ||
| async fn UserInfo(&self) -> Result<(bool, String), Error> { | ||
| blockdev_prop(&self.engine, self.parent_uuid, self.uuid, user_info_prop).await | ||
| } |
There was a problem hiding this comment.
Align UserInfo property emission behavior across API versions.
The UserInfo property uses the default change signal emission (no explicit emits_changed_signal attribute), while R0 and R2 explicitly set emits_changed_signal = "false". Since UserInfo is mutable (though the setter is currently commented out), this inconsistency could lead to different D-Bus notification behavior across API versions.
Apply this diff to align with R0/R2:
- #[zbus(property)]
+ #[zbus(property(emits_changed_signal = "false"))]
#[allow(non_snake_case)]
async fn UserInfo(&self) -> Result<(bool, String), Error> {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #[zbus(property)] | |
| #[allow(non_snake_case)] | |
| async fn UserInfo(&self) -> Result<(bool, String), Error> { | |
| blockdev_prop(&self.engine, self.parent_uuid, self.uuid, user_info_prop).await | |
| } | |
| #[zbus(property(emits_changed_signal = "false"))] | |
| #[allow(non_snake_case)] | |
| async fn UserInfo(&self) -> Result<(bool, String), Error> { | |
| blockdev_prop(&self.engine, self.parent_uuid, self.uuid, user_info_prop).await | |
| } |
🤖 Prompt for AI Agents
In src/dbus/blockdev/blockdev_3_7/mod.rs around lines 85 to 89, the UserInfo
property lacks the explicit emits_changed_signal attribute while R0 and R2 set
emits_changed_signal = "false"; update the zbus property attribute to include
emits_changed_signal = "false" (i.e., add #[zbus(property, emits_changed_signal
= "false")] above the UserInfo fn) so the property emission behavior matches
other API versions.
There was a problem hiding this comment.
The default is "true" not "false" as far as I understand.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check UserInfo property definitions in blockdev R0, R2, and R7 to verify emission attributes
echo "=== Blockdev R0 (3_0) UserInfo property ==="
rg -A 3 "async fn UserInfo" src/dbus/blockdev/blockdev_3_0/
echo -e "\n=== Blockdev R2 (3_2) UserInfo property ==="
rg -A 3 "async fn UserInfo" src/dbus/blockdev/blockdev_3_2/
echo -e "\n=== Blockdev R7 (3_7) UserInfo property ==="
rg -A 3 "async fn UserInfo" src/dbus/blockdev/blockdev_3_7/
echo -e "\n=== Check all emits_changed_signal attributes in blockdev files ==="
rg "emits_changed_signal" src/dbus/blockdev/ -n
Length of output: 8114
#!/bin/bash
# Check context around the emits_changed_signal = "false" lines to see which properties they belong to
echo "=== R0 (blockdev_3_0) line 93 context ==="
sed -n '90,96p' src/dbus/blockdev/blockdev_3_0/mod.rs
echo -e "\n=== R0 (blockdev_3_0) line 119 context ==="
sed -n '116,122p' src/dbus/blockdev/blockdev_3_0/mod.rs
echo -e "\n=== R2 (blockdev_3_2) line 89 context ==="
sed -n '86,92p' src/dbus/blockdev/blockdev_3_2/mod.rs
echo -e "\n=== R2 (blockdev_3_2) line 115 context ==="
sed -n '112,118p' src/dbus/blockdev/blockdev_3_2/mod.rs
echo -e "\n=== R7 (blockdev_3_7) line 127 context ==="
sed -n '124,130p' src/dbus/blockdev/blockdev_3_7/mod.rs
echo -e "\n=== R7 (blockdev_3_7) UserInfo property with more context ==="
sed -n '84,89p' src/dbus/blockdev/blockdev_3_7/mod.rs🧠 Learnings used
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
|
I don't really think we should error rapidly if one interface fails during registration. We should try to register them all. |
mulkieran
force-pushed
the
blockdev-changes
branch
from
63400e4 to
e119978
Compare
mulkieran
force-pushed
the
blockdev-changes
branch
from
63b3b1d to
455fece
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/dbus/filesystem/mod.rs (1)
51-122: Early return on registration failure contradicts stated design intent.Per the PR comment from @mulkieran: "I don't really think we should error rapidly if one interface fails during registration. We should try to register them all." The current implementation uses
?operators which fail fast on the first error.Based on learnings, filesystem registration failures should log a warning and continue processing rather than failing the entire operation.
Consider collecting errors and logging warnings while attempting all registrations:
- FilesystemR0::register( + if let Err(e) = FilesystemR0::register( engine.clone(), connection, manager, path.clone(), pool_uuid, uuid, ) - .await?; + .await + { + warn!("Failed to register FilesystemR0 at {}: {}", path, e); + } + // ... similar pattern for R1-R9 ...
🧹 Nitpick comments (2)
src/dbus/filesystem/mod.rs (2)
46-49: Counter increment occurs before registration success is confirmed.The counter is incremented via
fetch_addbefore any registration is attempted. If all registrations fail, the counter value is still consumed, leading to gaps in ObjectPath numbering. This is a minor concern but worth noting if path uniqueness tracking matters.
129-150: Consider resilient unregistration to match registration pattern.If registration adopts a "try all, log failures" pattern per the PR discussion, consider whether unregistration should follow the same approach. A failure to unregister one interface shouldn't necessarily prevent attempting to unregister others, as this could leave orphaned D-Bus objects.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- src/dbus/filesystem/filesystem_3_0/props.rs
- src/dbus/filesystem/filesystem_3_9/mod.rs
- src/dbus/filesystem/filesystem_3_0/methods.rs
- src/dbus/filesystem/filesystem_3_6/props.rs
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
📚 Learning: 2025-12-01T22:14:23.526Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/filesystem_3_6/mod.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/filesystem/shared.rssrc/dbus/filesystem/filesystem_3_5/mod.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_1/mod.rssrc/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/filesystem/shared.rs
🧬 Code graph analysis (7)
src/dbus/filesystem/filesystem_3_6/mod.rs (7)
src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_0/mod.rs (11)
new(34-46)register(48-60)connection(66-68)unregister(62-71)SetName(81-83)Created(87-89)Devnode(93-95)Pool(99-101)Size(105-107)Used(111-113)Uuid(117-119)src/dbus/filesystem/filesystem_3_1/mod.rs (11)
new(37-49)register(51-63)connection(69-71)unregister(65-74)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_2/mod.rs (11)
new(37-49)register(51-63)connection(69-71)unregister(65-74)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_3/mod.rs (11)
new(37-49)register(51-63)connection(69-71)unregister(65-74)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_4/mod.rs (11)
new(37-49)register(51-63)connection(69-71)unregister(65-74)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_5/mod.rs (11)
new(37-49)register(51-63)connection(69-71)unregister(65-74)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)
src/dbus/filesystem/filesystem_3_4/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/shared.rs (2)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
Name(83-85)Pool(89-91)Uuid(95-97)src/dbus/pool/pool_3_9/mod.rs (2)
Name(104-106)Uuid(98-100)
src/dbus/filesystem/filesystem_3_0/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/mod.rs (8)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
connection(68-70)register(50-62)unregister(64-73)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
register(48-60)unregister(62-71)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
register(54-66)unregister(68-77)
src/dbus/filesystem/filesystem_3_3/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_2/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (32)
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile check-typos, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
🔇 Additional comments (15)
src/dbus/filesystem/shared.rs (2)
13-30: LGTM - Setter correctly returnszbus::Error.The
set_filesystem_prophelper correctly returnsResult<(), zbus::Error>as required for D-Bus property setters, aligning with the PR comment that property setters must returnzbus::Errorinstead ofzbus::fdo::Error.
32-50: LGTM - Read-only property helper with proper error handling.The
filesystem_prophelper correctly returnsResult<R, zbus::fdo::Error>for read-only property access, with appropriate error messages when pool or filesystem is not found.src/dbus/filesystem/filesystem_3_5/mod.rs (2)
29-75: LGTM - FilesystemR5 struct and lifecycle methods.The struct definition and register/unregister lifecycle methods follow the established pattern used across other filesystem versions (R0, R3, R6). The constructor is appropriately private while register/unregister are public.
77-123: LGTM - D-Bus interface implementation.The interface implementation for
org.storage.stratis3.filesystem.r5correctly delegates to shared property helpers and theset_name_method. Property emission signals are appropriately configured for immutable vs mutable properties.src/dbus/filesystem/filesystem_3_6/mod.rs (3)
32-78: LGTM - FilesystemR6 struct and lifecycle methods.The struct definition and register/unregister lifecycle methods are consistent with the established patterns across filesystem versions.
121-132: LGTM - Property setter correctly returnszbus::Error.The
set_SizeLimitmethod correctly returnsResult<(), zbus::Error>(notzbus::fdo::Error), which aligns with the PR comment requirement that property setters must returnzbus::Error. This is properly wired throughset_filesystem_propwhich handles the error type correctly.
80-145: LGTM - D-Bus interface implementation for R6.The interface implementation for
org.storage.stratis3.filesystem.r6correctly adds theSizeLimitproperty with both getter and setter, while maintaining consistency with the base properties from earlier versions.src/dbus/filesystem/filesystem_3_0/mod.rs (3)
14-18: LGTM - Module structure and re-exports.The module correctly declares and re-exports the methods and props submodules. The re-exported helpers (
set_name_method, property accessors) enable code reuse across filesystem versions R1-R9.
26-72: LGTM - FilesystemR0 struct and lifecycle methods.The struct definition and register/unregister lifecycle methods establish the baseline pattern that all subsequent filesystem versions (R1-R9) follow.
74-120: LGTM - Base D-Bus interface implementation.The interface implementation for
org.storage.stratis3.filesystem.r0correctly implements the foundational filesystem properties with appropriate emission signals and error handling.src/dbus/filesystem/filesystem_3_3/mod.rs (2)
77-123: AI summary is inconsistent with actual code.The AI-generated summary claims FilesystemR3 includes properties like
UserInfo,NewPhysicalSize,HardwareInfo,Tier,PhysicalPath, andTotalPhysicalSize, but the actual implementation only includes the base properties:SetName,Created,Devnode,Pool,Size,Used, andUuid- identical to FilesystemR0.The implementation itself is correct and follows the established pattern.
29-75: LGTM - FilesystemR3 struct and lifecycle methods.The struct definition and register/unregister lifecycle methods are consistent with the established patterns across filesystem versions.
src/dbus/filesystem/filesystem_3_4/mod.rs (1)
29-123: LGTM! Implementation follows established patterns.The
FilesystemR4struct and its D-Bus interface implementation correctly follow the patterns established in other filesystem versions (R0-R3). The interface name is correctly versioned, property annotations are appropriate, and the delegation to shared helpers (filesystem_prop,set_name_method, etc.) is consistent.Note: The PR comment about property setters returning
zbus::Errorinstead ofzbus::fdo::Errordoes not apply here since this interface only defines property getters, not setters.src/dbus/filesystem/filesystem_3_2/mod.rs (1)
29-123: LGTM! Implementation is consistent with other filesystem versions.The
FilesystemR2implementation correctly mirrors the patterns in other filesystem versions. The interface is properly versioned asorg.storage.stratis3.filesystem.r2, and the delegation to shared property/method helpers is consistent.src/dbus/filesystem/filesystem_3_1/mod.rs (1)
29-123: LGTM! Implementation follows the established versioning pattern.The
FilesystemR1implementation is consistent with the other filesystem versions (R0, R2, R4, etc.). The interface naming, property annotations, and helper delegations are all correctly applied.
mulkieran
force-pushed
the
blockdev-changes
branch
from
455fece to
7eff06a
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
7-11: Missing import forhandle_action!macro.The
handle_action!macro is used at line 29, but it's not imported. This will cause a compilation error.src/dbus/filesystem/mod.rs (1)
53-133: Registration still uses fail-fast error handling.The current implementation uses
?operators which fail on the first registration error. Per the PR discussion and retrieved learnings, the registration process should attempt all interfaces and log warnings for failures rather than failing the entire operation.The previous review comment already addressed this issue with a suggested fix pattern using
if let Err(e)blocks with warning logs.
🧹 Nitpick comments (1)
src/dbus/filesystem/mod.rs (1)
140-162: Consider resilient error handling for unregistration as well.The
unregister_filesystemfunction also uses fail-fast?operators. For cleanup operations, it may be preferable to attempt unregistering all interfaces even if one fails, to avoid leaving partial registrations. Consider applying a similar pattern as suggested forregister_filesystem.pub async fn unregister_filesystem( connection: &Arc<Connection>, manager: &Lockable<Arc<RwLock<Manager>>>, path: &ObjectPath<'_>, ) -> StratisResult<FilesystemUuid> { - FilesystemR0::unregister(connection, path.clone()).await?; - FilesystemR1::unregister(connection, path.clone()).await?; - FilesystemR2::unregister(connection, path.clone()).await?; - FilesystemR3::unregister(connection, path.clone()).await?; - FilesystemR4::unregister(connection, path.clone()).await?; - FilesystemR5::unregister(connection, path.clone()).await?; - FilesystemR6::unregister(connection, path.clone()).await?; - FilesystemR7::unregister(connection, path.clone()).await?; - FilesystemR9::unregister(connection, path.clone()).await?; + if let Err(e) = FilesystemR0::unregister(connection, path.clone()).await { + warn!("Failed to unregister FilesystemR0 at {}: {}", path, e); + } + if let Err(e) = FilesystemR1::unregister(connection, path.clone()).await { + warn!("Failed to unregister FilesystemR1 at {}: {}", path, e); + } + // ... similar pattern for R2-R7, R9
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/dbus/filesystem/filesystem_3_5/mod.rs
- src/dbus/filesystem/filesystem_3_9/mod.rs
- src/dbus/filesystem/filesystem_3_0/props.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-01T22:14:23.526Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rssrc/dbus/filesystem/filesystem_3_6/props.rssrc/dbus/filesystem/shared.rssrc/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_1/mod.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/filesystem/filesystem_3_7/props.rssrc/dbus/filesystem/filesystem_3_6/mod.rssrc/dbus/filesystem/filesystem_3_7/mod.rssrc/dbus/filesystem/filesystem_3_0/methods.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/filesystem/shared.rs
🧬 Code graph analysis (7)
src/dbus/filesystem/filesystem_3_0/mod.rs (2)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_2/mod.rs (2)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/shared.rs (1)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
Name(83-85)Pool(89-91)Uuid(95-97)
src/dbus/filesystem/mod.rs (9)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
connection(68-70)register(50-62)unregister(64-73)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
register(48-60)unregister(62-71)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
register(54-66)unregister(68-77)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
register(56-68)unregister(70-79)
src/dbus/filesystem/filesystem_3_7/props.rs (2)
src/dbus/filesystem/filesystem_3_9/mod.rs (2)
Name(83-85)Pool(89-91)src/dbus/filesystem/filesystem_3_7/mod.rs (1)
Pool(138-140)
src/dbus/filesystem/filesystem_3_6/mod.rs (2)
src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)
src/dbus/filesystem/filesystem_3_7/mod.rs (11)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_0/mod.rs (10)
new(34-46)register(48-60)connection(66-68)SetName(81-83)Created(87-89)Devnode(93-95)Pool(99-101)Size(105-107)Used(111-113)Uuid(117-119)src/dbus/filesystem/filesystem_3_1/mod.rs (10)
new(37-49)register(51-63)connection(69-71)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_2/mod.rs (10)
new(37-49)register(51-63)connection(69-71)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_3/mod.rs (10)
new(37-49)register(51-63)connection(69-71)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_4/mod.rs (10)
new(37-49)register(51-63)connection(69-71)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_5/mod.rs (10)
new(37-49)register(51-63)connection(69-71)SetName(84-86)Created(90-92)Devnode(96-98)Pool(102-104)Size(108-110)Used(114-116)Uuid(120-122)src/dbus/filesystem/filesystem_3_9/mod.rs (5)
new(36-48)register(50-62)connection(68-70)Pool(89-91)Uuid(95-97)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (38)
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks-with-ci-repo
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: pylint
- GitHub Check: stratis-min-cli-checks
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: python-based-tests
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: stratis-cli-checks
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
🔇 Additional comments (16)
src/dbus/filesystem/filesystem_3_4/mod.rs (1)
1-123: LGTM!The FilesystemR4 implementation follows the established pattern used by other filesystem revisions. The struct, registration/unregistration methods, and D-Bus interface properties are correctly implemented with appropriate emission semantics (
constfor immutable properties likeCreated,Pool,Uuid;invalidatesforDevnode).src/dbus/filesystem/filesystem_3_0/methods.rs (1)
13-50: LGTM!The
set_name_methodfunction correctly handles allRenameActionvariants and provides appropriate D-Bus response tuples. The error handling for missing pools and unknown filesystems is comprehensive.src/dbus/filesystem/filesystem_3_6/props.rs (1)
1-42: LGTM!The property helpers correctly implement the size limit getter and setter. The setter appropriately returns
zbus::Error(per PR guidelines), and the error handling for parsing and pool operations is comprehensive.src/dbus/filesystem/filesystem_3_7/props.rs (1)
1-41: LGTM!The property helpers for origin and merge scheduling follow the established patterns. The setter correctly uses
zbus::Errorand handles bothPropChangeAction::NewValueandPropChangeAction::Identitycases appropriately.src/dbus/filesystem/filesystem_3_6/mod.rs (1)
1-145: LGTM!The FilesystemR6 implementation correctly follows the established pattern. Notable that the property setter
set_SizeLimitreturnszbus::Error(line 123) while getters returnzbus::fdo::Error, which aligns with the PR maintainer's guidance that property setters must returnzbus::Error.src/dbus/filesystem/filesystem_3_0/mod.rs (1)
1-120: Well-structured D-Bus interface implementation.The FilesystemR0 struct and its D-Bus interface are implemented correctly. The property emission signals are appropriately configured (
constfor immutable properties likeCreated,Pool, andUuid;invalidatesforDevnode). The delegation to shared helper functions (filesystem_prop,pool_prop,set_name_method) promotes code reuse across revisions.src/dbus/filesystem/shared.rs (2)
13-30: Correct error type for property setter.The
set_filesystem_propfunction correctly returnsResult<(), zbus::Error>rather thanzbus::fdo::Error, aligning with the PR requirement that property setters must returnzbus::Error. The callback signature also correctly useszbus::Error.
32-49: Clean property getter helper.The
filesystem_propfunction correctly useszbus::fdo::Errorfor property getters (standard for D-Bus property access). The error messages are descriptive, and the callback pattern allows flexible property value extraction.src/dbus/filesystem/filesystem_3_2/mod.rs (1)
1-123: Consistent implementation following R0 pattern.FilesystemR2 follows the established pattern from FilesystemR0, reusing the shared property helpers from
filesystem_3_0. The interface versioning (r2) is correctly applied. The code structure enables future revision-specific extensions while maintaining consistency.src/dbus/filesystem/filesystem_3_7/mod.rs (3)
117-128: Correct error type for MergeScheduled setter.The
set_MergeScheduledproperty setter correctly returnsResult<(), zbus::Error>as required by the PR specification, properly delegating toset_filesystem_propwhich maintains the same error type.
154-165: Correct error type for SizeLimit setter.The
set_SizeLimitproperty setter also correctly returnsResult<(), zbus::Error>, maintaining consistency with the error type requirements for property setters.
1-178: Well-implemented R7 revision with extended properties.FilesystemR7 properly extends the base filesystem interface with
MergeScheduled,Origin, andSizeLimitproperties. The implementation correctly reuses shared helpers fromfilesystem_3_0andfilesystem_3_6, and the new props are appropriately re-exported for use by other modules.src/dbus/filesystem/filesystem_3_1/mod.rs (1)
8-13: Verify the correct Error type for property returns.Line 9 imports
Errorfromzbus::fdo, which is then used in property return types throughout this file (lines 90, 96, 102, 108, 114). The PR comment states property setters should returnzbus::Errorinstead ofzbus::fdo::Error. Confirm whether this applies to property getters in this file and whether the import should be changed tozbus::Errorfor consistency with the D-Bus interface requirements.src/dbus/filesystem/filesystem_3_3/mod.rs (3)
29-75: FilesystemR3 state and register/unregister helpers look correct and align with existing patternsThe struct layout,
newconstructor, and the asyncregister/unregisterhelpers cleanly encapsulate the engine/manager/UUID context and simply propagate zbus errors viaStratisResult<()>, which is what callers need to implement best-effort multi-interface registration (log and continue on individual failures). This matches the existing filesystem registration approach described for pool methods.Based on learnings, this aligns with the intended best-effort registration behavior.
82-86: SetName delegation through shared helper is straightforward and consistent
SetNamejust forwards toset_name_methodwith the engine, parent UUID, filesystem UUID, and name, preserving the existing Stratis method contract((bool, FilesystemUuid), u16, String)without introducing new error paths. The zbus attributes and out-arg names are also consistent with other D-Bus methods.
88-122: Property accessors correctly use shared helpers and appropriate D‑Bus metadataThe Created/Devnode/Size/Used/Pool/Uuid properties all delegate to shared helpers (
filesystem_prop,pool_prop), returnResult<_, zbus::fdo::Error>where needed, and use sensibleemits_changed_signalannotations (constfor immutable values,invalidatesfor Devnode, default for changing size/usage). This keeps the filesystem r3 surface aligned with earlier versions while centralizing logic in the shared helpers.
mulkieran
force-pushed
the
blockdev-changes
branch
from
7eff06a to
a54bfc5
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
7-11: Missing import forhandle_action!macro.The
handle_action!macro is used at line 29, but it's not imported. This will cause a compilation error.src/dbus/filesystem/mod.rs (1)
55-144: Early return on registration failure contradicts stated design intent.Per the PR comment from @mulkieran, registration should attempt all interfaces rather than failing fast. The current
?operators will abort on the first failure.Based on learnings, filesystem registration failures should log a warning and continue processing.
🧹 Nitpick comments (2)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
13-50: Implementation looks correct with proper error handling.The function correctly handles all
RenameActionoutcomes and maps them to appropriate D-Bus return values. TheFIXMEat line 36 acknowledges the missing signal emission—consider tracking this as a follow-up task.Would you like me to open an issue to track the signal emission TODO?
src/dbus/filesystem/filesystem_3_4/mod.rs (1)
29-75: Consider deduplicating the R2/R3/R4 filesystem interface boilerplate
FilesystemR2,FilesystemR3, andFilesystemR4have identical struct fields,new,register/unregister, and property implementations, differing only in type/interface names. A small macro or generic helper could reduce duplication and the chance of future drift, especially if more revisions are added.Also applies to: 77-123
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_8/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- src/dbus/filesystem/filesystem_3_6/props.rs
- src/dbus/filesystem/filesystem_3_7/props.rs
- src/dbus/filesystem/filesystem_3_7/mod.rs
- src/dbus/filesystem/filesystem_3_1/mod.rs
- src/dbus/filesystem/filesystem_3_6/mod.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-01T22:14:23.526Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/filesystem_3_5/mod.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/filesystem/shared.rssrc/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_0/props.rssrc/dbus/filesystem/filesystem_3_9/mod.rssrc/dbus/filesystem/filesystem_3_0/methods.rssrc/dbus/filesystem/filesystem_3_8/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/filesystem/shared.rssrc/dbus/filesystem/filesystem_3_0/props.rs
🧬 Code graph analysis (8)
src/dbus/filesystem/filesystem_3_5/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_0/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_2/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (10)
new(34-46)register(48-60)unregister(62-71)SetName(81-83)Created(87-89)Devnode(93-95)Pool(99-101)Size(105-107)Used(111-113)Uuid(117-119)
src/dbus/filesystem/filesystem_3_4/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/mod.rs (11)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
connection(71-73)register(53-65)unregister(67-76)src/dbus/util.rs (14)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
register(48-60)unregister(62-71)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
register(51-63)unregister(65-74)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
register(54-66)unregister(68-77)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
register(56-68)unregister(70-79)src/dbus/filesystem/filesystem_3_8/mod.rs (2)
register(53-65)unregister(67-76)
src/dbus/filesystem/filesystem_3_0/props.rs (2)
src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/filesystem_3_0/mod.rs (1)
new(34-46)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
Uuid(117-119)
src/dbus/filesystem/filesystem_3_8/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (5)
created_prop(15-17)devnode_prop(19-28)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
Pool(138-140)Uuid(175-177)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: python-based-tests
🔇 Additional comments (14)
src/dbus/filesystem/filesystem_3_5/mod.rs (2)
29-75: Struct and lifecycle methods are well-structured.The
FilesystemR5struct and itsregister/unregistermethods follow the established pattern used across other filesystem revisions, ensuring consistency.
77-123: D-Bus interface implementation is consistent with the established pattern.The property accessors correctly delegate to shared helpers, and the
SetNamemethod properly uses the sharedset_name_method. Property emission signals are appropriately configured.src/dbus/filesystem/mod.rs (2)
151-174: Verify if unregister should also continue on failure.The
unregister_filesystemfunction uses?operators similar toregister_filesystem. If the design intent (attempt all operations rather than failing fast) applies here as well, consider logging warnings and continuing through all unregistrations to ensure cleanup is as complete as possible.
50-54: Path generation is thread-safe.Using
Ordering::AcqRelwithfetch_addensures the counter increment is properly synchronized across concurrent registrations.src/dbus/filesystem/filesystem_3_0/mod.rs (2)
26-72: Struct and lifecycle methods follow the established pattern.The
FilesystemR0struct and itsregister/unregistermethods are consistent with other filesystem revisions, enabling proper D-Bus object lifecycle management.
74-120: D-Bus interface implementation is correct and consistent.Properties and methods correctly delegate to shared helpers. The
SetNamemethod returns the standard tuple format for D-Bus method results.src/dbus/filesystem/shared.rs (2)
13-30: Setter returns correct error type per PR requirements.The
set_filesystem_propfunction correctly returnsResult<(), zbus::Error>rather thanzbus::fdo::Error, which aligns with the PR comment requiring property setters to returnzbus::Error.
32-50: Helper function is well-designed with proper error handling.The
filesystem_propfunction provides a clean abstraction for property access, handling missing pool/filesystem cases with descriptive error messages and delegating value extraction to the callback.src/dbus/filesystem/filesystem_3_3/mod.rs (1)
29-75: FilesystemR3 D‑Bus surface mirrors existing pattern and looks correctStruct layout, register/unregister, and the r3 interface all align with the shared helpers (
filesystem_prop,pool_prop,set_name_method) and other revisions. Getters cleanly returnResult<_, Error>without panics, and the lifecycle methods simply wrapobject_server().at/remove, which is appropriate at this level.Also applies to: 77-123
src/dbus/filesystem/filesystem_3_0/props.rs (1)
15-53: Filesystem property helpers are well‑behaved and non‑panickingThe props in this module now compute values directly (
devnode_propviapath_to_mount_filesystem) and convert missing pool paths intoError::Failedrather than panicking. This is appropriate for D‑Bus property access and matches how these helpers are consumed by the R* filesystem interfaces.src/dbus/filesystem/filesystem_3_9/mod.rs (2)
31-77: FilesystemR9 D‑Bus interface wiring looks consistent and correctThe R9 struct, lifecycle methods, and interface (including MergeScheduled/Origin/SizeLimit/Used) follow the same pattern as earlier revisions, delegating cleanly to
filesystem_prop,set_filesystem_prop, andpool_prop. Property getters returnResult<_, Error>as expected, andUuidis exposed read‑only.Also applies to: 79-113, 127-175
114-125:andsrc/dbus/filesystem/filesystem_3_2/mod.rs (1)
29-75: FilesystemR2 implementation is sound; multi‑interface registration semantics belong at the callerThe R2 struct,
register/unregister, and interface implementation match the shared pattern and correctly use the common helpers. These functions intentionally wrap a singleobject_server().at/removecall; the “don’t fail fast if one interface registration fails” behavior should be implemented in the code that invokesregisterfor multiple revisions, not inside this per‑revision helper.Also applies to: 77-123
src/dbus/filesystem/filesystem_3_8/mod.rs (1)
31-77: FilesystemR8 D‑Bus implementation is consistent with other revisionsThe R8 struct, registration helpers, and interface (including MergeScheduled/SizeLimit setters and related getters) cleanly reuse
filesystem_prop,set_filesystem_prop, andpool_prop, with setters returningResult<(), zbus::Error>. This stays consistent with the R9 pattern and the shared helper contracts.Also applies to: 79-175
mulkieran
force-pushed
the
blockdev-changes
branch
from
a54bfc5 to
8bb0a20
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
src/dbus/filesystem/mod.rs (1)
55-144: Registration still fails fast, contradicting stated design intent.The current implementation continues to use the
?operator for each interface registration (R0 through R9), which causes the entire registration to abort if any single interface fails. This contradicts the PR comment from @mulkieran stating: "should not error rapidly if one interface fails during registration."Per the existing review suggestion, consider collecting errors and logging warnings while attempting all registrations to ensure maximum D-Bus surface availability even if some interfaces fail.
src/dbus/filesystem/filesystem_3_8/mod.rs (1)
115-126: Verify return type compatibility for property setters.Similar to FilesystemR7, these setters (
set_MergeScheduledandset_SizeLimit) call prop functions that may returnResult<(), zbus::fdo::Error>instead of the requiredResult<(), zbus::Error>. Ensure thatset_merge_scheduled_prop(imported from filesystem_3_7) andset_size_limit_prop(from filesystem_3_6) have been updated to returnzbus::Errorper the PR objectives.Also applies to: 158-169
🧹 Nitpick comments (1)
src/dbus/filesystem/mod.rs (1)
156-165: Consider non-failing unregistration pattern for consistency.Similar to the registration flow,
unregister_filesystemuses fail-fast error propagation. For consistency and to ensure maximum cleanup even if individual interface unregistrations fail, consider logging warnings and continuing through all interfaces.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_8/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- src/dbus/filesystem/filesystem_3_6/mod.rs
- src/dbus/filesystem/filesystem_3_7/props.rs
- src/dbus/filesystem/filesystem_3_3/mod.rs
- src/dbus/filesystem/filesystem_3_0/props.rs
- src/dbus/filesystem/filesystem_3_1/mod.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-01T22:14:23.526Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/filesystem_3_9/mod.rssrc/dbus/filesystem/filesystem_3_6/props.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_5/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rssrc/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_0/methods.rssrc/dbus/filesystem/shared.rssrc/dbus/filesystem/filesystem_3_7/mod.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/filesystem/filesystem_3_8/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/filesystem/filesystem_3_6/props.rssrc/dbus/filesystem/shared.rs
🧬 Code graph analysis (9)
src/dbus/filesystem/filesystem_3_9/mod.rs (5)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/filesystem_3_7/props.rs (3)
merge_scheduled_prop(23-25)origin_prop(14-21)set_merge_scheduled_prop(27-41)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)
src/dbus/filesystem/filesystem_3_0/mod.rs (2)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)
src/dbus/filesystem/filesystem_3_5/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_2/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (8)
Name(99-101)SetName(81-83)Created(87-89)Devnode(93-95)Pool(105-107)Size(111-113)Used(117-119)Uuid(123-125)
src/dbus/filesystem/mod.rs (10)
src/dbus/filesystem/filesystem_3_9/mod.rs (3)
connection(72-74)register(54-66)unregister(68-77)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
register(48-60)unregister(62-71)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
register(55-67)unregister(69-78)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
register(57-69)unregister(71-80)src/dbus/filesystem/filesystem_3_8/mod.rs (2)
register(54-66)unregister(68-77)
src/dbus/filesystem/filesystem_3_0/methods.rs (12)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/filesystem/filesystem_3_0/mod.rs (1)
Uuid(123-125)src/dbus/filesystem/filesystem_3_1/mod.rs (1)
Uuid(127-129)src/dbus/filesystem/filesystem_3_2/mod.rs (1)
Uuid(127-129)src/dbus/filesystem/filesystem_3_3/mod.rs (1)
Uuid(126-128)src/dbus/filesystem/filesystem_3_4/mod.rs (1)
Uuid(127-129)src/dbus/filesystem/filesystem_3_5/mod.rs (1)
Uuid(127-129)src/dbus/filesystem/filesystem_3_6/mod.rs (1)
Uuid(149-151)src/dbus/filesystem/filesystem_3_7/mod.rs (1)
Uuid(182-184)src/dbus/filesystem/filesystem_3_8/mod.rs (1)
Uuid(179-181)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Uuid(179-181)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)
src/dbus/filesystem/shared.rs (11)
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
Name(99-101)src/dbus/filesystem/filesystem_3_1/mod.rs (1)
Name(103-105)src/dbus/filesystem/filesystem_3_2/mod.rs (1)
Name(103-105)src/dbus/filesystem/filesystem_3_3/mod.rs (1)
Name(103-105)src/dbus/filesystem/filesystem_3_4/mod.rs (1)
Name(103-105)src/dbus/filesystem/filesystem_3_5/mod.rs (1)
Name(103-105)src/dbus/filesystem/filesystem_3_6/mod.rs (1)
Name(106-108)src/dbus/filesystem/filesystem_3_7/mod.rs (1)
Name(133-135)src/dbus/filesystem/filesystem_3_8/mod.rs (1)
Name(130-132)src/dbus/filesystem/filesystem_3_9/mod.rs (1)
Name(130-132)src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)
src/dbus/filesystem/filesystem_3_7/mod.rs (5)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (9)
Name(99-101)new(34-46)SetName(81-83)Created(87-89)Devnode(93-95)Pool(105-107)Size(111-113)Used(117-119)Uuid(123-125)src/dbus/filesystem/filesystem_3_7/props.rs (2)
merge_scheduled_prop(23-25)origin_prop(14-21)
src/dbus/filesystem/filesystem_3_8/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/filesystem_3_7/props.rs (3)
merge_scheduled_prop(23-25)origin_prop(14-21)set_merge_scheduled_prop(27-41)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: python-based-tests
🔇 Additional comments (12)
src/dbus/filesystem/filesystem_3_6/props.rs (2)
14-19: Filesystem size_limit getter matches existing D‑Bus prop patternThe getter follows the established
(bool, String)pattern viaoption_to_tuple, and the mapping fromOption<Bytes>to decimal string looks consistent with other props. No issues from a correctness or API-shape standpoint.
21-41: VerifyBytestype definition andset_fs_size_limitsignature before proceedingThe implementation correctly returns
Result<(), zbus::Error>and usesError::Failure(...)for error cases. However, verification needed:
- Confirm
devicemapper::Bytesinner type compatibility with theu128parse operation- Verify
set_fs_size_limitparameter type expectations match what's being passed- The optional refactor using
Option::map(...).transpose()is stylistic; current match pattern is acceptable- Ensure D-Bus signals are implemented elsewhere before resolving the FIXME comment
src/dbus/filesystem/filesystem_3_5/mod.rs (1)
30-130: LGTM! FilesystemR5 implementation follows established pattern.The implementation is consistent with other filesystem revision modules (R0, R1, R2, etc.), properly wiring the D-Bus interface with standard property helpers and lifecycle management.
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
26-126: LGTM! FilesystemR0 establishes solid foundation pattern.The implementation correctly establishes the baseline D-Bus filesystem interface pattern that other revisions (R1-R9) follow, with proper lifecycle management and property delegation to shared helpers.
src/dbus/filesystem/shared.rs (1)
13-50: LGTM! Error types correctly match zbus property conventions.The implementation correctly uses
zbus::Errorfor the property setter (set_filesystem_prop) andzbus::fdo::Errorfor the property getter (filesystem_prop), aligning with the PR requirement that "property setter must return zbus::Error instead of zbus::fdo::Error."src/dbus/filesystem/filesystem_3_4/mod.rs (1)
30-130: LGTM! FilesystemR4 implementation is consistent.The implementation correctly follows the established pattern for filesystem revision interfaces with proper structure and delegation to shared helpers.
src/dbus/filesystem/filesystem_3_9/mod.rs (1)
32-182: LGTM! FilesystemR9 provides the most complete D-Bus interface.The implementation correctly extends the base pattern with additional properties for snapshot management (Origin, MergeScheduled) and size control (SizeLimit), properly delegating to helpers from earlier revisions and using the correct error types for property setters.
src/dbus/filesystem/filesystem_3_2/mod.rs (1)
30-130: LGTM! FilesystemR2 implementation is consistent.The implementation correctly follows the established pattern for filesystem revision interfaces with proper structure and delegation to shared helpers.
src/dbus/filesystem/filesystem_3_7/mod.rs (3)
57-69: LGTM: Registration implementation is clean.The async registration pattern correctly instantiates the interface and attaches it to the D-Bus object server. Error propagation using
?is appropriate here for individual interface registration.
161-172: Verify return type compatibility for set_SizeLimit.Similar to
set_MergeScheduled, this setter callsset_size_limit_propwhich may returnResult<(), zbus::fdo::Error>instead of the requiredResult<(), zbus::Error>. Ensureset_size_limit_prophas been updated to returnzbus::Errorper the PR objectives.
118-129: Unable to verify this review comment due to repository access limitations. However, based on zbus library documentation, the stated requirement appears potentially incorrect: D-Bus property setters should returnResult<(), zbus::fdo::Error>(the Freedesktop D-Bus method error enum), notzbus::Error(which is for transport/encoding-level failures). The review comment claims property setters "must returnzbus::Errorinstead ofzbus::fdo::Error," but zbus documentation indicates the opposite — D-Bus method and property error replies should usezbus::fdo::Errorwhich implements theDBusErrortrait for D-Bus error handling. Verify the PR objectives and actual function implementations in the props module to clarify the correct error type.src/dbus/filesystem/filesystem_3_8/mod.rs (1)
32-78: LGTM: Clean implementation following established patterns.FilesystemR8 correctly reuses property helpers from filesystem_3_7 and follows the same registration lifecycle as other filesystem revisions. The structure is consistent and maintainable.
mulkieran
force-pushed
the
blockdev-changes
branch
from
8bb0a20 to
1e98b5c
Compare
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (7)
src/dbus/pool/pool_3_0/methods.rs (1)
132-167: Clarify destroy semantics: engine vs DBus UUIDs and unregister failuresTwo things to straighten out in
destroy_filesystems_method:
Collected
uuidsvector is unused in the return valueAfter a successful engine destroy you build a local
uuids: Vec<FilesystemUuid>fromunregister_filesystem, but then returnvfrom the engine result instead:let mut uuids = Vec::new(); match changed.changed() { Some((v, _)) => { for op in filesystems.iter() { match unregister_filesystem(connection, manager, op).await { Ok(uuid) => { uuids.push(uuid); } // ... } } ((true, v), DbusErrorEnum::OK as u16, OK_STRING.to_string()) } // ... }Either the intention is to return the UUIDs that were actually unregistered (
uuids), orvfrom the engine result is authoritative and the local vector can be dropped. As written, the extra collection is dead weight and obscures the true semantics. This was already raised on a previous commit; it’s still unresolved here.Unregister failures short-circuit the entire operation
Any
unregister_filesystemerror immediately returns a DBus error and stops processing remaining filesystems. That conflicts with the documented behavior for similar pool methods (3_6) where DBus registration/unregistration failures after a successful engine change are logged and the method still returns success. Based on learnings, the expectation is:
- Engine destroy succeeds → operation should generally be reported as success.
- Individual DBus unregister failures should be logged and not abort the whole call.
Concrete direction:
- Decide whether the return payload should be
voruuidsand delete the other path accordingly.- Replace the early
returnon unregister error with awarn!(...)and continue, mirroring the create‑path semantics.src/dbus/blockdev/blockdev_3_0/methods.rs (1)
7-11: Missing import forhandle_action!macro.The
handle_action!macro is used at line 29, but it's not imported. This will cause a compilation error.Apply this diff to add the missing import:
use crate::{ dbus::{consts::OK_STRING, types::DbusErrorEnum, util::tuple_to_option}, engine::{DevUuid, Engine, PoolIdentifier, PoolUuid, RenameAction}, + handle_action, stratis::StratisError, };src/dbus/filesystem/mod.rs (1)
58-147: Registration still fails fast, contradicting PR design intent.Per the PR comment: "I don't really think we should error rapidly if one interface fails during registration. We should try to register them all." The current implementation continues to use
?operators which abort on the first error, preventing subsequent interface registrations.Based on learnings, filesystem registration failures should log a warning and continue processing rather than failing the entire operation. Additionally, see
src/dbus/manager/mod.rslines 190-233 for the correct resilient pattern usingif let Err(e)withwarn!.src/dbus/manager/manager_3_8/methods.rs (1)
194-237: Guard held across await points and filesystem registration still fails fast.Same issues as flagged in the past review:
The
guardfrom line 195 is held across multiple.awaitcalls (lines 212-223, 226-232). Extract needed data and drop the guard before awaiting.Filesystem registration failure (lines 217-221) returns an error and aborts. Per codebase patterns and learnings, this should log a warning and continue processing remaining filesystems.
Refer to
src/dbus/pool/mod.rslines 26-85 for the correct pattern where filesystem registration errors are logged withwarn!while continuing to process remaining items.Based on learnings, similar D-Bus methods should continue processing when individual registrations fail.
src/dbus/blockdev/blockdev_3_3/mod.rs (1)
102-119: AlignUserInfoproperty’s emits_changed_signal with other versions
set_UserInfocorrectly returnsResult<(), zbus::Error>, but theUserInfoproperty itself still uses the default#[zbus(property)], which impliesemits_changed_signal = "true". BlockdevR2 (and related versions) explicitly set this to"false".For consistency across blockdev interface versions, consider:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn UserInfo(&self) -> Result<(bool, String), Error> {src/dbus/blockdev/blockdev_3_6/mod.rs (1)
100-117: MakeUserInfo’s emits_changed_signal explicit to match other blockdev versionsIn BlockdevR6,
set_UserInfois correctly typed asResult<(), zbus::Error>, but theUserInfoproperty itself omitsemits_changed_signal, so it defaults to"true". R0/R2 set this to"false".To keep behavior consistent across versions:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn UserInfo(&self) -> Result<(bool, String), Error> {src/dbus/manager/manager_3_0/methods.rs (1)
167-205: Still holding manager write lock acrossdestroy_pool/unregister_poolawaits (possible deadlock)
destroy_pool_methodkeepsmanager_lockin scope while:
- Awaiting
engine.destroy_pool(uuid), and- Calling
unregister_pool(connection, manager, &pool).await.If either of those needs to acquire the same manager lock (very likely for
unregister_pool), the future can deadlock, which matches the earlier review concern. Please drop/scope the write guard immediately after extracting the UUID.For example:
- let manager_lock = manager.write().await; - let uuid = match manager_lock.pool_get_uuid(&pool) { - Some(u) => u, - None => { - return ( - default_return, - DbusErrorEnum::ERROR as u16, - format!("Object path {pool} not associated with pool"), - ); - } - }; + let uuid = { + let manager_lock = manager.write().await; + match manager_lock.pool_get_uuid(&pool) { + Some(u) => u, + None => { + return ( + default_return, + DbusErrorEnum::ERROR as u16, + format!("Object path {pool} not associated with pool"), + ); + } + } + };
🧹 Nitpick comments (7)
src/dbus/pool/pool_3_0/methods.rs (1)
289-302: Minor: consider using the returneduuidfor clarity inset_name_methodIn the
RenameAction::Renamed(uuid)arm you ignore theuuidvalue except in the warning message and always returnpool_uuid:Ok(RenameAction::Renamed(uuid)) => { match manager.read().await.pool_get_path(&pool_uuid) { /* ... */ } ( (true, pool_uuid), DbusErrorEnum::OK as u16, OK_STRING.to_string(), ) }If
RenameAction::Renamedever carried a different identifier in the future, this would be confusing. Even if UUIDs are guaranteed to be stable across renames today, using theuuidfrom the action consistently (both in the lookup and the return tuple) would make intent clearer:- Ok(RenameAction::Renamed(uuid)) => { - match manager.read().await.pool_get_path(&pool_uuid) { + Ok(RenameAction::Renamed(uuid)) => { + match manager.read().await.pool_get_path(&uuid) { // ... }; ( - (true, pool_uuid), + (true, uuid), DbusErrorEnum::OK as u16, OK_STRING.to_string(), ) }Not critical, but it tightens up the API and avoids potential confusion between
pool_uuidanduuid.src/dbus/manager/manager_3_9/methods.rs (1)
86-129: Drop the pool guard before async DBus registration to avoid holding locks across.awaitIn
StartAction::Startedyou obtain a pool guard and then keep it alive across all the async registration work and signal emission:let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { /* ... */ }; let mut fs_paths = Vec::default(); for fs_uuid in guard .filesystems() .into_iter() .map(|(_, fs_uuid, _)| fs_uuid) .collect::<Vec<_>>() { let fs_path = register_filesystem(..., fs_uuid).await?; fs_paths.push(fs_path); } let (pool_path, dev_paths) = register_pool(...).await?; if guard.is_encrypted() { send_locked_pools_signals(connection).await; } send_stopped_pools_signals(connection).await;You only need data derived from the guard (
filesystems()andis_encrypted()), not the guard itself, during the async registration. Holding it across.awaitpoints:
- Extends the lifetime of whatever internal lock
get_pooluses, and- Increases the chance of contention or deadlocks if registration helpers ever need their own engine locks.
Safer pattern:
- Extract the filesystem UUIDs and
is_encryptedinto local values.- Drop the guard (e.g., by limiting its scope or calling
drop(guard)).- Perform DBus registration and signal emission using only those values.
For example:
let guard = /* get_pool */; let fs_uuids: Vec<_> = guard .filesystems() .into_iter() .map(|(_, fs_uuid, _)| fs_uuid) .collect(); let encrypted = guard.is_encrypted(); drop(guard); // Now do register_filesystem / register_pool / send_*_signals using fs_uuids + encryptedThis reduces lock hold time and keeps async boundaries cleaner without changing external behavior.
src/dbus/manager/manager_3_4/methods.rs (1)
84-103: Consider non-fail-fast behavior for filesystem registration.The current implementation returns immediately on the first filesystem registration error (lines 97-100), preventing subsequent filesystems from being registered. Based on learnings, when filesystem registration fails after successful pool start, the code should log a warning and continue processing remaining filesystems rather than failing the entire operation.
Based on learnings, apply this pattern:
for fs_uuid in guard .filesystems() .into_iter() .map(|(_, fs_uuid, _)| fs_uuid) .collect::<Vec<_>>() { - let fs_path = match register_filesystem( + match register_filesystem( engine, connection, manager, counter, pool_uuid, fs_uuid, ) .await { - Ok(fp) => fp, + Ok(fp) => fs_paths.push(fp), Err(e) => { - let (rc, rs) = engine_to_dbus_err_tuple(&e); - return (default_return, rc, rs); + warn!("Unable to register object path for filesystem with UUID {fs_uuid} belonging to pool {pool_uuid} on the D-Bus: {e}"); } - }; - fs_paths.push(fs_path); + } }src/dbus/blockdev/blockdev_3_9/mod.rs (1)
16-29: Consider consolidating import statements.The imports from
crate::are split across three separate blocks (lines 16-19, 20-27, 29). While functionally correct, consolidating these into a singleuse crate::block would improve readability and align with the import style in other files.-use crate::dbus::blockdev::blockdev_3_0::{ - devnode_prop, hardware_info_prop, init_time_prop, physical_path_prop, pool_prop, tier_prop, - total_physical_size_prop, user_info_prop, -}; -use crate::{ +use crate::dbus::blockdev::{ + blockdev_3_0::{ + devnode_prop, hardware_info_prop, init_time_prop, physical_path_prop, pool_prop, + tier_prop, total_physical_size_prop, user_info_prop, + }, + blockdev_3_3::{new_physical_size_prop, set_user_info_prop}, + shared::{blockdev_prop, set_blockdev_prop}, +}; +use crate::{ dbus::{ - blockdev::shared::{blockdev_prop, set_blockdev_prop}, manager::Manager, }, engine::{DevUuid, Engine, Lockable, PoolUuid}, stratis::StratisResult, }; - -use crate::dbus::blockdev::blockdev_3_3::{new_physical_size_prop, set_user_info_prop};src/dbus/util.rs (1)
183-189: Consider documenting or implementing filesystem background signals
send_fs_background_signalsis currently a no‑op, but it’s called from the timer path with the diffs returned byengine.fs_evented(). If dropping all FS diffs is intentional for now, a brief comment/TODO would help avoid confusion; otherwise, wiring FS signals similar to pools would complete the background signal story.src/dbus/pool/pool_3_0/mod.rs (1)
82-98: Re-check CreateFilesystems behavior on partial registration failures
CreateFilesystemsforwards directly tocreate_filesystems_method, which (persrc/dbus/pool/pool_3_0/methods.rssnippet) currently returns an error on the first failedregister_filesystemcall inside the loop. That is a fail-fast behavior: if one filesystem fails to register on D-Bus, the wholeCreateFilesystemscall errors even though prior filesystems may have been created successfully.Given the prior pattern in
pool_3_6/methods.rs—where filesystem registration failures after successful creation are logged and the method continues processing remaining filesystems—this might be stricter than intended for the r0 interface as well. It would be more consistent with that behavior (and with the PR objective about not erroring rapidly on registration) to log the failure and continue registering subsequent filesystems, returning success plus only the successfully registered object paths.If r0 is also expected to tolerate partial registration failures, consider updating
create_filesystems_methodaccordingly (e.g., warn andcontinuein the error branch instead ofreturn), mirroring the 3.6 implementation.Based on learnings, this would align r0 with the documented behavior where registration failures don’t cause the entire operation to fail.
src/dbus/filesystem/filesystem_3_7/mod.rs (1)
35-80: FilesystemR7 registration helpers are straightforward; consider consistency with other modules
FilesystemR7::registerandFilesystemR7::unregistercorrectly wrapobject_server().at/.removeand returnStratisResult<()>. The struct holds only what it needs (no connection field), which keeps it lean.For consistency with
ManagerR0andPoolR0, you might optionally take&Arc<dyn Engine>inregisterand clone internally rather than takingArc<dyn Engine>by value, but this is stylistic and not a correctness issue.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (65)
Cargo.toml(2 hunks)src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_8/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)src/dbus/manager/manager_3_0/methods.rs(1 hunks)src/dbus/manager/manager_3_0/mod.rs(1 hunks)src/dbus/manager/manager_3_0/props.rs(1 hunks)src/dbus/manager/manager_3_1/mod.rs(1 hunks)src/dbus/manager/manager_3_2/methods.rs(1 hunks)src/dbus/manager/manager_3_2/mod.rs(1 hunks)src/dbus/manager/manager_3_2/props.rs(1 hunks)src/dbus/manager/manager_3_3/mod.rs(1 hunks)src/dbus/manager/manager_3_4/methods.rs(1 hunks)src/dbus/manager/manager_3_4/mod.rs(1 hunks)src/dbus/manager/manager_3_5/mod.rs(1 hunks)src/dbus/manager/manager_3_6/methods.rs(1 hunks)src/dbus/manager/manager_3_6/mod.rs(1 hunks)src/dbus/manager/manager_3_7/mod.rs(1 hunks)src/dbus/manager/manager_3_8/methods.rs(1 hunks)src/dbus/manager/manager_3_8/mod.rs(1 hunks)src/dbus/manager/manager_3_8/props.rs(1 hunks)src/dbus/manager/manager_3_9/methods.rs(1 hunks)src/dbus/manager/manager_3_9/mod.rs(1 hunks)src/dbus/manager/mod.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/dbus/pool/pool_3_0/methods.rs(1 hunks)src/dbus/pool/pool_3_0/mod.rs(1 hunks)src/dbus/pool/pool_3_0/props.rs(1 hunks)src/dbus/pool/pool_3_9/mod.rs(1 hunks)src/dbus/types.rs(1 hunks)src/dbus/util.rs(1 hunks)src/engine/mod.rs(1 hunks)src/engine/types/keys.rs(4 hunks)src/engine/types/mod.rs(4 hunks)src/stratis/dm.rs(4 hunks)src/stratis/timer.rs(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (24)
- src/dbus/manager/manager_3_8/props.rs
- src/dbus/mod.rs
- src/dbus/manager/manager_3_2/props.rs
- src/engine/mod.rs
- src/dbus/manager/manager_3_2/methods.rs
- src/engine/types/mod.rs
- src/dbus/blockdev/blockdev_3_3/props.rs
- src/dbus/types.rs
- src/dbus/filesystem/filesystem_3_6/props.rs
- src/dbus/blockdev/mod.rs
- src/dbus/filesystem/filesystem_3_0/methods.rs
- src/dbus/blockdev/shared.rs
- src/dbus/blockdev/blockdev_3_0/props.rs
- src/dbus/filesystem/filesystem_3_6/mod.rs
- src/dbus/manager/manager_3_1/mod.rs
- src/dbus/filesystem/filesystem_3_5/mod.rs
- src/dbus/filesystem/shared.rs
- src/dbus/blockdev/blockdev_3_1/mod.rs
- src/dbus/pool/pool_3_9/mod.rs
- src/dbus/blockdev/blockdev_3_2/mod.rs
- src/dbus/blockdev/blockdev_3_5/mod.rs
- src/dbus/manager/manager_3_6/mod.rs
- src/stratis/dm.rs
- src/dbus/manager/manager_3_0/props.rs
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
📚 Learning: 2025-12-01T22:14:23.526Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.526Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/pool/mod.rssrc/dbus/manager/manager_3_9/methods.rssrc/dbus/manager/manager_3_6/methods.rssrc/dbus/filesystem/filesystem_3_0/props.rssrc/dbus/manager/manager_3_3/mod.rssrc/dbus/manager/manager_3_4/methods.rssrc/dbus/manager/mod.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/manager/manager_3_5/mod.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_1/mod.rssrc/dbus/manager/manager_3_8/mod.rssrc/dbus/manager/manager_3_4/mod.rssrc/dbus/blockdev/blockdev_3_3/mod.rssrc/dbus/filesystem/filesystem_3_7/props.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/blockdev/blockdev_3_0/methods.rssrc/dbus/pool/pool_3_0/methods.rssrc/dbus/manager/manager_3_9/mod.rssrc/dbus/util.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/manager/manager_3_0/methods.rssrc/dbus/manager/manager_3_8/methods.rssrc/stratis/timer.rssrc/dbus/filesystem/filesystem_3_9/mod.rssrc/dbus/manager/manager_3_7/mod.rssrc/dbus/filesystem/filesystem_3_7/mod.rssrc/dbus/manager/manager_3_2/mod.rssrc/dbus/blockdev/blockdev_3_7/mod.rssrc/dbus/filesystem/filesystem_3_8/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rssrc/dbus/filesystem/mod.rssrc/dbus/manager/manager_3_0/mod.rssrc/dbus/pool/pool_3_0/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/pool/mod.rssrc/dbus/manager/manager_3_9/methods.rssrc/dbus/manager/manager_3_6/methods.rssrc/dbus/filesystem/filesystem_3_0/props.rssrc/dbus/manager/manager_3_3/mod.rssrc/dbus/manager/manager_3_4/methods.rssrc/dbus/manager/manager_3_5/mod.rssrc/engine/types/keys.rssrc/dbus/pool/pool_3_0/props.rssrc/dbus/manager/manager_3_8/mod.rssrc/dbus/manager/manager_3_4/mod.rssrc/dbus/blockdev/blockdev_3_3/mod.rssrc/dbus/pool/pool_3_0/methods.rssrc/dbus/manager/manager_3_9/mod.rssrc/dbus/util.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/manager/manager_3_0/methods.rssrc/dbus/manager/manager_3_8/methods.rssrc/stratis/timer.rssrc/dbus/manager/manager_3_7/mod.rssrc/dbus/manager/manager_3_2/mod.rssrc/dbus/blockdev/blockdev_3_7/mod.rssrc/dbus/manager/manager_3_0/mod.rssrc/dbus/pool/pool_3_0/mod.rs
📚 Learning: 2025-09-05T14:32:42.528Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3898
File: src/engine/sim_engine/pool.rs:934-948
Timestamp: 2025-09-05T14:32:42.528Z
Learning: In src/engine/sim_engine/pool.rs, the start_encrypt_pool method intentionally creates a SizedKeyMemory with 1 byte allocated but 0 length reported - this is to avoid NULL pointer issues while simulating an empty key slice in the sim engine.
Applied to files:
src/dbus/manager/manager_3_9/methods.rssrc/dbus/manager/manager_3_4/methods.rssrc/dbus/pool/pool_3_0/props.rssrc/dbus/manager/manager_3_8/methods.rssrc/dbus/pool/pool_3_0/mod.rs
🧬 Code graph analysis (33)
src/dbus/pool/mod.rs (3)
src/dbus/blockdev/mod.rs (1)
register_blockdev(43-148)src/dbus/util.rs (15)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)src/dbus/pool/pool_3_0/mod.rs (4)
Uuid(164-166)register(53-71)new(37-51)unregister(73-79)
src/dbus/manager/manager_3_6/methods.rs (3)
src/dbus/pool/mod.rs (1)
unregister_pool(88-112)src/dbus/util.rs (18)
engine_to_dbus_err_tuple(70-76)send_locked_pools_signals(191-237)send_stopped_pools_signals(239-399)connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)src/dbus/manager/manager_3_2/methods.rs (1)
stop_pool_method(123-185)
src/dbus/filesystem/filesystem_3_0/props.rs (2)
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
Name(99-101)src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)
src/dbus/manager/manager_3_3/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/stratis/keys.rs (1)
engine(28-46)src/dbus/util.rs (15)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)
src/dbus/manager/manager_3_4/methods.rs (7)
src/dbus/filesystem/mod.rs (1)
register_filesystem(42-150)src/dbus/util.rs (17)
engine_to_dbus_err_tuple(70-76)tuple_to_option(30-36)connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)src/stratis/keys.rs (1)
engine(28-46)src/dbus/manager/manager_3_2/methods.rs (1)
start_pool_method(28-121)src/dbus/manager/manager_3_8/methods.rs (1)
start_pool_method(141-255)src/dbus/manager/manager_3_9/methods.rs (1)
start_pool_method(32-147)src/dbus/manager/manager_3_4/mod.rs (1)
new(45-57)
src/dbus/manager/mod.rs (10)
src/dbus/manager/manager_3_8/mod.rs (1)
register(62-79)src/dbus/manager/manager_3_9/mod.rs (1)
register(61-78)src/dbus/manager/manager_3_7/mod.rs (1)
register(57-74)src/dbus/manager/manager_3_6/mod.rs (1)
register(60-77)src/dbus/manager/manager_3_5/mod.rs (1)
register(56-73)src/dbus/manager/manager_3_4/mod.rs (1)
register(59-76)src/dbus/manager/manager_3_3/mod.rs (1)
register(57-74)src/dbus/manager/manager_3_2/mod.rs (1)
register(58-75)src/dbus/manager/manager_3_1/mod.rs (1)
register(51-68)src/dbus/manager/manager_3_0/mod.rs (1)
register(53-70)
src/dbus/manager/manager_3_5/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (15)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)
src/dbus/filesystem/filesystem_3_0/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_1/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/pool/pool_3_0/props.rs (3)
src/dbus/util.rs (1)
option_to_tuple(39-44)src/dbus/pool/pool_3_0/mod.rs (1)
Name(170-172)src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)
src/dbus/manager/manager_3_8/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_8/methods.rs (4)
create_pool_method(40-138)key_desc(56-59)devs(55-55)clevis_info(60-60)src/dbus/manager/manager_3_8/props.rs (1)
stopped_pools_prop(12-16)
src/dbus/manager/manager_3_4/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_4/methods.rs (1)
start_pool_method(28-134)src/dbus/util.rs (15)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)
src/dbus/blockdev/blockdev_3_3/mod.rs (2)
src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/filesystem/filesystem_3_4/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/blockdev/blockdev_3_0/methods.rs (13)
src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/mod.rs (1)
Uuid(126-128)src/dbus/blockdev/blockdev_3_1/mod.rs (1)
Uuid(122-124)src/dbus/blockdev/blockdev_3_2/mod.rs (1)
Uuid(122-124)src/dbus/blockdev/blockdev_3_3/mod.rs (1)
Uuid(137-139)src/dbus/blockdev/blockdev_3_4/mod.rs (1)
Uuid(134-136)src/dbus/blockdev/blockdev_3_5/mod.rs (1)
Uuid(134-136)src/dbus/blockdev/blockdev_3_6/mod.rs (1)
Uuid(135-137)src/dbus/blockdev/blockdev_3_7/mod.rs (1)
Uuid(135-137)src/dbus/blockdev/blockdev_3_8/mod.rs (1)
Uuid(134-136)src/dbus/blockdev/blockdev_3_9/mod.rs (1)
Uuid(134-136)src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)src/dbus/pool/mod.rs (1)
pool(71-71)
src/dbus/pool/pool_3_0/methods.rs (2)
src/dbus/filesystem/mod.rs (2)
register_filesystem(42-150)unregister_filesystem(152-178)src/dbus/util.rs (16)
engine_to_dbus_err_tuple(70-76)send_pool_name_signal(401-417)tuple_to_option(30-36)connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)
src/dbus/blockdev/blockdev_3_4/mod.rs (9)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)src/dbus/blockdev/blockdev_3_0/mod.rs (12)
new(38-50)register(52-64)unregister(66-75)Devnode(88-90)HardwareInfo(94-102)UserInfo(106-108)InitializationTime(112-116)Pool(120-122)Uuid(126-128)Tier(132-134)PhysicalPath(138-146)TotalPhysicalSize(150-158)src/dbus/blockdev/blockdev_3_1/mod.rs (12)
new(34-46)register(48-60)unregister(62-71)Devnode(84-86)HardwareInfo(90-98)UserInfo(102-104)InitializationTime(108-112)Pool(116-118)Uuid(122-124)Tier(128-130)PhysicalPath(134-142)TotalPhysicalSize(146-154)src/dbus/blockdev/blockdev_3_2/mod.rs (12)
new(34-46)register(48-60)unregister(62-71)Devnode(84-86)HardwareInfo(90-98)UserInfo(102-104)InitializationTime(108-112)Pool(116-118)Uuid(122-124)Tier(128-130)PhysicalPath(134-142)TotalPhysicalSize(146-154)src/dbus/blockdev/blockdev_3_7/mod.rs (13)
new(40-52)register(54-66)unregister(68-77)Devnode(84-86)HardwareInfo(90-98)UserInfo(102-104)set_UserInfo(108-117)InitializationTime(121-125)Pool(129-131)Uuid(135-137)Tier(141-143)PhysicalPath(147-155)TotalPhysicalSize(159-167)src/dbus/blockdev/blockdev_3_8/mod.rs (13)
new(39-51)register(53-65)unregister(67-76)Devnode(83-85)HardwareInfo(89-97)UserInfo(101-103)set_UserInfo(107-116)InitializationTime(120-124)Pool(128-130)Uuid(134-136)Tier(140-142)PhysicalPath(146-154)TotalPhysicalSize(158-166)src/dbus/blockdev/blockdev_3_9/mod.rs (13)
new(39-51)register(53-65)unregister(67-76)Devnode(83-85)HardwareInfo(89-97)UserInfo(101-103)set_UserInfo(107-116)InitializationTime(120-124)Pool(128-130)Uuid(134-136)Tier(140-142)PhysicalPath(146-154)TotalPhysicalSize(158-166)
src/dbus/manager/manager_3_9/mod.rs (4)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_9/methods.rs (1)
start_pool_method(32-147)src/dbus/manager/manager_3_8/mod.rs (10)
new(48-60)register(62-79)Version(87-89)StoppedPools(93-95)ListKeys(98-100)SetKey(103-109)UnsetKey(112-114)CreatePool(118-142)DestroyPool(145-147)StartPool(150-175)src/dbus/manager/manager_3_0/mod.rs (8)
new(39-51)register(53-70)Version(78-80)ListKeys(89-91)SetKey(94-100)UnsetKey(103-105)CreatePool(109-128)DestroyPool(131-133)
src/dbus/blockdev/blockdev_3_9/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/props.rs (6)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)src/dbus/blockdev/blockdev_3_0/mod.rs (11)
new(38-50)register(52-64)connection(70-72)unregister(66-75)Devnode(88-90)HardwareInfo(94-102)UserInfo(106-108)InitializationTime(112-116)Pool(120-122)Uuid(126-128)Tier(132-134)src/dbus/blockdev/blockdev_3_3/mod.rs (12)
new(42-54)register(56-68)connection(74-76)unregister(70-79)Devnode(86-88)HardwareInfo(92-100)UserInfo(104-106)set_UserInfo(110-119)InitializationTime(123-127)Pool(131-133)Uuid(137-139)Tier(143-145)src/dbus/blockdev/blockdev_3_4/mod.rs (12)
new(39-51)register(53-65)connection(71-73)unregister(67-76)Devnode(83-85)HardwareInfo(89-97)UserInfo(101-103)set_UserInfo(107-116)InitializationTime(120-124)Pool(128-130)Uuid(134-136)Tier(140-142)src/dbus/blockdev/blockdev_3_5/mod.rs (12)
new(39-51)register(53-65)connection(71-73)unregister(67-76)Devnode(83-85)HardwareInfo(89-97)UserInfo(101-103)set_UserInfo(107-116)InitializationTime(120-124)Pool(128-130)Uuid(134-136)Tier(140-142)src/dbus/blockdev/blockdev_3_6/mod.rs (12)
new(40-52)register(54-66)connection(72-74)unregister(68-77)Devnode(84-86)HardwareInfo(90-98)UserInfo(102-104)set_UserInfo(108-117)InitializationTime(121-125)Pool(129-131)Uuid(135-137)Tier(141-143)src/dbus/blockdev/blockdev_3_7/mod.rs (12)
new(40-52)register(54-66)connection(72-74)unregister(68-77)Devnode(84-86)HardwareInfo(90-98)UserInfo(102-104)set_UserInfo(108-117)InitializationTime(121-125)Pool(129-131)Uuid(135-137)Tier(141-143)src/dbus/blockdev/blockdev_3_8/mod.rs (12)
new(39-51)register(53-65)connection(71-73)unregister(67-76)Devnode(83-85)HardwareInfo(89-97)UserInfo(101-103)set_UserInfo(107-116)InitializationTime(120-124)Pool(128-130)Uuid(134-136)Tier(140-142)
src/dbus/util.rs (1)
src/dbus/types.rs (3)
from(52-115)from(241-247)from(269-275)
src/dbus/blockdev/blockdev_3_0/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(28-44)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/mod.rs (5)
new(42-54)Devnode(86-88)Pool(131-133)Uuid(137-139)Tier(143-145)
src/dbus/manager/manager_3_8/methods.rs (5)
src/dbus/filesystem/mod.rs (1)
register_filesystem(42-150)src/dbus/pool/mod.rs (2)
pool(71-71)register_pool(27-86)src/dbus/util.rs (19)
engine_to_dbus_err_tuple(70-76)send_locked_pools_signals(191-237)send_stopped_pools_signals(239-399)tuple_to_option(30-36)connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)src/dbus/manager/manager_3_0/methods.rs (2)
create_pool_method(99-157)devs(111-111)src/dbus/manager/manager_3_2/methods.rs (2)
start_pool_method(28-121)guard(72-76)
src/stratis/timer.rs (1)
src/dbus/util.rs (17)
send_fs_background_signals(184-189)send_pool_background_signals(79-181)connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)
src/dbus/filesystem/filesystem_3_9/mod.rs (5)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/pool_3_0/props.rs (3)
name_prop(12-15)size_prop(17-19)used_prop(21-27)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/engine/types/actions.rs (3)
new(235-237)new(311-313)new(586-589)
src/dbus/manager/manager_3_7/mod.rs (2)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/util.rs (15)
connection(94-96)connection(114-116)connection(141-143)connection(161-163)connection(200-202)connection(219-221)connection(248-250)connection(267-269)connection(286-288)connection(305-307)connection(324-326)connection(343-345)connection(362-364)connection(381-383)connection(402-404)
src/dbus/filesystem/filesystem_3_7/mod.rs (5)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-42)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_7/props.rs (3)
merge_scheduled_prop(23-25)origin_prop(14-21)set_merge_scheduled_prop(27-41)
src/dbus/manager/manager_3_2/mod.rs (3)
src/dbus/manager/manager_3_0/props.rs (1)
version_prop(12-14)src/dbus/manager/manager_3_2/methods.rs (1)
refresh_state_method(187-192)src/dbus/manager/manager_3_2/props.rs (1)
stopped_pools_prop(12-16)
src/dbus/blockdev/blockdev_3_8/mod.rs (4)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)src/dbus/blockdev/blockdev_3_0/mod.rs (7)
new(38-50)register(52-64)connection(70-72)unregister(66-75)Pool(120-122)Uuid(126-128)Tier(132-134)
src/dbus/blockdev/blockdev_3_6/mod.rs (4)
src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)src/dbus/blockdev/blockdev_3_0/mod.rs (4)
new(38-50)Pool(120-122)Uuid(126-128)Tier(132-134)
src/dbus/filesystem/filesystem_3_2/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (4)
Name(99-101)new(34-46)Pool(105-107)Uuid(123-125)
src/dbus/filesystem/mod.rs (10)
src/dbus/filesystem/filesystem_3_9/mod.rs (2)
register(54-66)unregister(68-77)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
register(48-60)unregister(62-71)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
register(52-64)unregister(66-75)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
register(55-67)unregister(69-78)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
register(57-69)unregister(71-80)src/dbus/filesystem/filesystem_3_8/mod.rs (2)
register(54-66)unregister(68-77)
src/dbus/manager/manager_3_0/mod.rs (2)
src/dbus/manager/manager_3_0/methods.rs (2)
create_pool_method(99-157)devs(111-111)src/dbus/manager/manager_3_0/props.rs (2)
locked_pools_prop(16-18)version_prop(12-14)
src/dbus/pool/pool_3_0/mod.rs (3)
src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/pool/pool_3_0/methods.rs (3)
create_filesystems_method(30-121)filesystems(40-52)filesystems(134-137)src/dbus/pool/pool_3_0/props.rs (5)
allocated_prop(29-31)encrypted_prop(33-35)name_prop(12-15)size_prop(17-19)used_prop(21-27)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: python-based-tests
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
| use zbus::{ | ||
| fdo::Error, | ||
| interface, | ||
| zvariant::{ObjectPath, OwnedObjectPath}, | ||
| Connection, |
There was a problem hiding this comment.
Incorrect error type: should use zbus::Error not zbus::fdo::Error.
Line 9 imports zbus::fdo::Error, but per PR objectives, property setters must return zbus::Error instead of zbus::fdo::Error. This affects all property methods in the interface (lines 87, 93, 99, 105, 111, 117).
Apply this diff:
use zbus::{
- fdo::Error,
+ Error,
interface,
zvariant::{ObjectPath, OwnedObjectPath},
Connection,
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| use zbus::{ | |
| fdo::Error, | |
| interface, | |
| zvariant::{ObjectPath, OwnedObjectPath}, | |
| Connection, | |
| use zbus::{ | |
| Error, | |
| interface, | |
| zvariant::{ObjectPath, OwnedObjectPath}, | |
| Connection, | |
| }; |
| let id = match id_type { | ||
| "uuid" => match PoolUuid::parse_str(id) { | ||
| Ok(u) => PoolIdentifier::Uuid(u), | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| }, | ||
| "name" => PoolIdentifier::Name(Name::new(id.to_string())), | ||
| _ => { | ||
| return ( | ||
| default_return, | ||
| DbusErrorEnum::ERROR as u16, | ||
| format!("ID type {id_type} not recognized"), | ||
| ); | ||
| } | ||
| }; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for PoolUuid::parse_str definition
rg "fn parse_str" --type rust -A 3 | head -30Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Search for engine_to_dbus_err_tuple definition
rg "fn engine_to_dbus_err_tuple" --type rust -A 5Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Look for PoolUuid type and error handling
rg "type PoolUuid|struct PoolUuid" --type rust -A 2Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Search for error trait implementations involving UUID or parse errors
rg "impl.*From.*uuid" --type rust -A 3Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Find similar error handling patterns in manager methods
rg "parse_str.*Err\(" --type rust -B 2 -A 5Repository: stratis-storage/stratisd
Length of output: 192
🌐 Web query:
PoolUuid stratisd uuid parse error handling
💡 Result:
Short answer: that error comes from Rust's UUID parsing (uuid::Uuid::parse_str / FromStr) when stratisd tries to convert a pool UUID string into its PoolUuid/Uuid type. Handle it by validating/normalizing the input, using Uuid::parse_str (or FromStr) and mapping the crate ParseError into a clear, user-facing Stratis error (or DBus error) rather than panicking — e.g. return an Err with a helpful message or a specific error variant you can surface to the caller. See stratisd source for where pool UUIDs are used and the uuid crate docs for parsing behavior and error type.
References:
- stratisd repository (project location / source). [1]
- uuid crate parse_str / FromStr documentation (ParseError returned by parsing). [2]
Fix PoolUuid::parse_str error handling: wrong error type for engine_to_dbus_err_tuple
In the "uuid" branch, passing the parse error directly to engine_to_dbus_err_tuple causes a type mismatch. The uuid::Uuid::parse_str returns a ParseError from the uuid crate, not a StratisError, and these need explicit conversion.
Suggested approaches:
- Return an explicit DBus error for invalid UUID input:
"uuid" => match PoolUuid::parse_str(id) {
Ok(u) => PoolIdentifier::Uuid(u),
Err(e) => {
return (
default_return,
DbusErrorEnum::ERROR as u16,
format!("Invalid pool UUID {id}: {e}"),
);
}
},- Or wrap the error into
StratisErrorif that conversion is available:
"uuid" => PoolIdentifier::Uuid(
PoolUuid::parse_str(id)
.map_err(|e| StratisError::Msg(format!("Invalid pool UUID: {e}")))
.and_then(|u| ...)?
),🤖 Prompt for AI Agents
In src/dbus/manager/manager_3_9/methods.rs around lines 55 to 71, the "uuid"
branch passes the ParseError from PoolUuid::parse_str into
engine_to_dbus_err_tuple which expects a StratisError; change the error handling
so the parse error is not forwarded directly — either return an explicit DBus
error for invalid UUID input (returning default_return, DbusErrorEnum::ERROR as
u16, and a formatted message that includes the pool id and parse error) or
convert/wrap the uuid::ParseError into a StratisError before calling
engine_to_dbus_err_tuple so the function receives the expected error type.
| Ok(StartAction::Started(pool_uuid)) => { | ||
| let guard = match engine.get_pool(PoolIdentifier::Uuid(pool_uuid)).await { | ||
| Some(g) => g, | ||
| None => { | ||
| return ( | ||
| default_return, | ||
| DbusErrorEnum::ERROR as u16, | ||
| format!("No pool found for newly started pool with UUID {pool_uuid}"), | ||
| ); | ||
| } | ||
| }; | ||
| let mut fs_paths = Vec::default(); | ||
| for fs_uuid in guard | ||
| .filesystems() | ||
| .into_iter() | ||
| .map(|(_, fs_uuid, _)| fs_uuid) | ||
| .collect::<Vec<_>>() | ||
| { | ||
| let fs_path = match register_filesystem( | ||
| engine, connection, manager, counter, pool_uuid, fs_uuid, | ||
| ) | ||
| .await | ||
| { | ||
| Ok(fp) => fp, | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| }; | ||
| fs_paths.push(fs_path); | ||
| } | ||
| let (pool_path, dev_paths) = | ||
| match register_pool(engine, connection, manager, counter, pool_uuid).await { | ||
| Ok(pp) => pp, | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| }; | ||
|
|
||
| if guard.is_encrypted() { | ||
| send_locked_pools_signals(connection).await; | ||
| } | ||
| send_stopped_pools_signals(connection).await; | ||
|
|
||
| ( | ||
| (true, (pool_path, dev_paths, fs_paths)), | ||
| DbusErrorEnum::OK as u16, | ||
| OK_STRING.to_string(), | ||
| ) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's understand the directory structure and find relevant files
git ls-files src/dbus/ | grep -E "(manager|pool)" | head -20Repository: stratis-storage/stratisd
Length of output: 192
Align start_pool error handling with pool create/destroy pattern: use best-effort registration instead of failing fast
The StartAction::Started branch currently returns errors immediately on any register_filesystem or register_pool failure. This contradicts the established pattern in pool create/destroy methods (e.g., pool_3_6), which intentionally log registration failures and continue after successful engine operations, returning success with whatever was successfully registered on D-Bus.
Replace the early return statements on registration errors with warn! logs instead:
- When
register_filesystemfails for a filesystem, log the error and skip that filesystem rather than aborting the entire operation - When
register_poolfails, log the error but still return((true, (pool_path, dev_paths, fs_paths)), OK, "OK")with what was successfully registered
This aligns start_pool with the codebase's "don't fail fast on D-Bus registration" design goal and allows the operation to report success when the engine pool start succeeds, even if some D-Bus objects fail to register.
🤖 Prompt for AI Agents
In src/dbus/manager/manager_3_9/methods.rs around lines 86 to 135, the
StartAction::Started branch currently returns immediately on any
register_filesystem or register_pool error; change this to the
pool-create/destroy pattern: when register_filesystem fails, log a warn! with
the error and skip that filesystem (do not return), and when register_pool
fails, log a warn! with the error but do not abort—still construct and return
the success tuple ((true, (pool_path, dev_paths, fs_paths)), OK, "OK") using
whatever pool_path/dev_paths/fs_paths were successfully registered; ensure no
early returns for registration errors and preserve sending the locked/stopped
signals as before.
| Ok(Ok(changed)) => { | ||
| let mut object_paths = Vec::new(); | ||
| match changed.changed() { | ||
| Some(v) => { | ||
| for (_, uuid, _) in v { | ||
| match register_filesystem( | ||
| engine, connection, manager, counter, pool_uuid, uuid, | ||
| ) | ||
| .await | ||
| { | ||
| Ok(path) => { | ||
| object_paths.push(path); | ||
| } | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } | ||
| } | ||
| } | ||
| ( | ||
| (true, object_paths), | ||
| DbusErrorEnum::OK as u16, | ||
| OK_STRING.to_string(), | ||
| ) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the pool methods files to understand the repository structure
fd -t f "pool_3_0" --max-results 5Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
fd -t f "pool.*methods.rs" --max-results 20Repository: stratis-storage/stratisd
Length of output: 192
Align filesystem registration error handling with pool_3_6 pattern
The create_filesystems_method in pool_3_0 currently fails the entire operation on the first filesystem registration error, but pool_3_6 intentionally logs a warning and continues processing remaining filesystems. This allows the method to succeed while returning only the successfully registered filesystems, avoiding treating D-Bus wiring failures as engine-level failures.
Update the error handling to log and continue instead of returning early:
for (_, uuid, _) in v {
match register_filesystem(..., uuid).await {
Ok(path) => object_paths.push(path),
Err(e) => {
let (rc, rs) = engine_to_dbus_err_tuple(&e);
warn!("Failed to register filesystem: {}", e);
continue;
}
}
}Then return ((true, object_paths), OK, "OK") with the successfully registered subset.
🤖 Prompt for AI Agents
In src/dbus/pool/pool_3_0/methods.rs around lines 80 to 103, the loop currently
returns early on the first register_filesystem error which aborts the whole
operation; instead, change the error-handling to log a warning and continue so
remaining filesystems are attempted and only successfully registered paths are
returned. Specifically, inside the for (_, uuid, _) in v { ... } match arm,
replace the Err(e) branch so it converts the error if needed
(engine_to_dbus_err_tuple(&e) can still be called for context), emits a warn!
with the error message, then continue the loop rather than returning; leave the
final return as ((true, object_paths), DbusErrorEnum::OK as u16,
OK_STRING.to_string()) so the method succeeds with the subset of successfully
registered filesystems.
| let guard_res = engine | ||
| .get_mut_pool(PoolIdentifier::Uuid(pool_uuid)) | ||
| .await | ||
| .ok_or_else(|| StratisError::Msg(format!("No pool associated with uuid {pool_uuid}"))); | ||
| match tokio::task::spawn_blocking(move || { | ||
| let mut guard = guard_res?; | ||
| let (name, _, pool) = guard.as_mut_tuple(); | ||
| handle_action!(pool.snapshot_filesystem( | ||
| name.to_string().as_str(), | ||
| pool_uuid, | ||
| fs_uuid, | ||
| snapshot_name.as_str() | ||
| )) | ||
| .map(|act| match act { | ||
| CreateAction::Created((uuid, _)) => CreateAction::Created(uuid), | ||
| CreateAction::Identity => CreateAction::Identity, | ||
| }) | ||
| }) | ||
| .await | ||
| { | ||
| Ok(Ok(CreateAction::Created(snapshot_uuid))) => { | ||
| let path = match register_filesystem( | ||
| engine, | ||
| connection, | ||
| manager, | ||
| counter, | ||
| pool_uuid, | ||
| snapshot_uuid, | ||
| ) | ||
| .await | ||
| { | ||
| Ok(p) => p, | ||
| Err(e) => { | ||
| let (rc, rs) = engine_to_dbus_err_tuple(&e); | ||
| return (default_return, rc, rs); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /tmp && find . -name "pool_3_0" -type d 2>/dev/null | head -5Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
fd "pool_3_0" --type dRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
fd "methods.rs" | grep poolRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
fd "pool" --type d src/dbus | head -10Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
git ls-files "src/dbus/pool*" | grep methodsRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
git ls-files "src/dbus/pool/" | head -20Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
ls -la src/dbus/pool/Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '208,243p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_6/methods.rs | sed -n '88,120p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -A 30 "create_filesystems" src/dbus/pool/pool_3_6/methods.rs | head -60Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -A 30 "create_filesystems" src/dbus/pool/pool_3_0/methods.rs | head -80Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -B 5 -A 15 "register_filesystem.*await" src/dbus/pool/pool_3_0/methods.rs | head -50Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -B 5 -A 20 "warn!" src/dbus/pool/pool_3_6/methods.rs | grep -A 10 register_filesystemRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -B 20 "snapshot_filesystem_method" src/dbus/pool/pool_3_0/methods.rs | grep -A 5 "let default_return"Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '180,210p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '170,250p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg "snapshot_filesystem_method" src/dbus/pool/pool_3_6/methods.rsRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
git ls-files "src/dbus/pool/pool_*" | sortRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
fd "pool_" src/dbus/pool --type d | sortRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg "snapshot_filesystem" src/dbus/pool --type rust -lRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -B 5 "snapshot_filesystem_method" src/dbus/pool/pool_3_1/methods.rs | head -40Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -A 40 "snapshot_filesystem_method" src/dbus/pool/pool_3_1/methods.rs | head -60Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -A 30 "create_filesystems" src/dbus/pool/pool_3_1/methods.rs | head -50Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_6/methods.rs | sed -n '85,115p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '210,250p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
rg -B 50 "fn snapshot_filesystem_method" src/dbus/pool/pool_3_0/methods.rs | grep -A 2 "-> Rc"Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '145,180p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
cat -n src/dbus/pool/pool_3_0/methods.rs | sed -n '200,250p'Repository: stratis-storage/stratisd
Length of output: 192
Align snapshot registration error handling with best-effort semantics
In snapshot_filesystem_method, a failure in register_filesystem after a successful engine snapshot currently causes the whole method to error. However, pool_3_6's create_filesystems and other pool methods intentionally warn and continue when registration fails, allowing the operation to succeed while logging that the object may not be visible to clients.
Update the error handling to match this best-effort approach:
let path = match register_filesystem(...).await {
Ok(p) => p,
Err(e) => {
warn!("register_filesystem failed: snapshot may not be visible to clients: {}", e);
ObjectPath::default()
}
};
// Return ((true, path), OK, "OK") to indicate successful snapshot creation
return ((true, path), OK, "OK".to_string());This keeps snapshot semantics consistent with create_filesystems behavior across API versions while still surfacing operational issues via logs.
🤖 Prompt for AI Agents
In src/dbus/pool/pool_3_0/methods.rs around lines 208 to 243, the code currently
returns an error when register_filesystem fails after a successful engine
snapshot; change this to best-effort semantics: if
register_filesystem(...).await returns Ok(p) use p, but if it returns Err(e) log
a warning like "register_filesystem failed: snapshot may not be visible to
clients: {e}" and set path to ObjectPath::default(); then return ((true, path),
OK, "OK".to_string()) to indicate the snapshot succeeded even though
registration failed.
| pub fn used_prop(guard: SomeLockReadGuard<PoolUuid, dyn Pool>) -> (bool, String) { | ||
| let (b, used) = option_to_tuple( | ||
| guard.total_physical_used().map(|s| s.bytes()), | ||
| Bytes::from(0u64), | ||
| ); | ||
| (b, (*used).to_string()) | ||
| } |
There was a problem hiding this comment.
Fix type/logic in used_prop to follow the String-based option pattern
used_prop currently mixes total_physical_used().map(|s| s.bytes()) with a Bytes::from(0u64) default, then stringifies via (*used).to_string(). This is both hard to read and likely type-incorrect compared to the established pattern used elsewhere (e.g., blockdev new_physical_size_prop, which maps to String directly and uses String::new() as the default).
Consider simplifying to something along these lines so the option type is consistently Option<String> and the default is a String:
-pub fn used_prop(guard: SomeLockReadGuard<PoolUuid, dyn Pool>) -> (bool, String) {
- let (b, used) = option_to_tuple(
- guard.total_physical_used().map(|s| s.bytes()),
- Bytes::from(0u64),
- );
- (b, (*used).to_string())
-}
+pub fn used_prop(guard: SomeLockReadGuard<PoolUuid, dyn Pool>) -> (bool, String) {
+ option_to_tuple(
+ guard
+ .total_physical_used()
+ .map(|s| (*s.bytes()).to_string()),
+ String::new(),
+ )
+}This matches the rest of the D‑Bus property helpers that expose optional numeric values as (bool, String) and avoids potential type mismatches between the mapped value and the default.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pub fn used_prop(guard: SomeLockReadGuard<PoolUuid, dyn Pool>) -> (bool, String) { | |
| let (b, used) = option_to_tuple( | |
| guard.total_physical_used().map(|s| s.bytes()), | |
| Bytes::from(0u64), | |
| ); | |
| (b, (*used).to_string()) | |
| } | |
| pub fn used_prop(guard: SomeLockReadGuard<PoolUuid, dyn Pool>) -> (bool, String) { | |
| option_to_tuple( | |
| guard | |
| .total_physical_used() | |
| .map(|s| (*s.bytes()).to_string()), | |
| String::new(), | |
| ) | |
| } |
🤖 Prompt for AI Agents
In src/dbus/pool/pool_3_0/props.rs around lines 21 to 27, change used_prop to
operate on Option<String> instead of mixing numeric Bytes with a
Bytes::from(0u64) default: map total_physical_used() to a String (e.g.
guard.total_physical_used().map(|s| s.bytes().to_string())), call
option_to_tuple with that Option<String> and use String::new() as the default,
and return the resulting (bool, String); this keeps the option type consistent
with other property helpers and avoids type mismatches.
1e98b5c to
d8b6907
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
src/dbus/filesystem/mod.rs (1)
42-150: Avoid fail‑fast filesystem interface registration; attempt all and log failures.
register_filesystemuses?on eachFilesystemR0..R9::register(...)call, so a single failing revision aborts the function, contradicting the stated requirement that registration “should not error rapidly if one interface fails” and that we should attempt to register all interfaces.Consider following the pool/filesystem creation pattern: invoke each
FilesystemR*::registerin turn, log any individual errors, and still returnOk(path)if at least one interface successfully registers (optionally erroring only if all registrations fail).src/dbus/blockdev/mod.rs (1)
43-148: Blockdev registration should not fail fast and must avoid leaving orphaned interfaces.
register_blockdevshort‑circuits on the first failedBlockdevR*::registervia?, which both:
- Conflicts with the requirement to keep registering remaining interfaces when one fails.
- Can leave already registered interfaces (R0..Rk−1) pinned in the object server without a corresponding manager mapping, since
add_blockdevonly runs after all?succeed.Consider:
- Registering each
BlockdevR*inif let Err(e) = ...blocks, logging individual failures, and tracking whether at least one succeeded.- Ensuring
manager.add_blockdev(&path, dev_uuid)is called whenever there is at least one successful registration, so the manager mapping is consistent with the object server.- Optionally returning an error only if all interface registrations fail.
This would align blockdev behavior with the filesystem/pool registration pattern and the PR objective.
src/dbus/blockdev/blockdev_3_6/mod.rs (1)
100-104: Add explicit emits_changed_signal for consistency across revisions.The user_info property is missing an explicit
emits_changed_signalattribute (defaulting to "true"), while BlockdevR0 and BlockdevR2 explicitly set it to "false". For consistency across interface versions, the emission behavior should align.Apply this diff:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn user_info(&self) -> Result<(bool, String), Error> {Based on past review comments and consistency with other blockdev revisions.
src/dbus/blockdev/blockdev_3_3/mod.rs (1)
102-106: Add explicit emits_changed_signal for consistency across revisions.The user_info property lacks an explicit
emits_changed_signalsetting (defaulting to "true"), while BlockdevR0, BlockdevR2, and BlockdevR9 explicitly set it to "false". Since R3 provides a setter (set_UserInfo), the emission behavior should align with other revisions.Apply this diff:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] #[allow(non_snake_case)] async fn user_info(&self) -> Result<(bool, String), Error> {Based on past review comments and consistency with other blockdev revisions.
🧹 Nitpick comments (5)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
13-50: set_name_method correctly wraps rename_filesystem resultsThe method’s use of
get_mut_pool,RenameAction, andDbusErrorEnummirrors the established pattern from other D-Bus methods: it distinguishes missing pool/filesystem, successful renames, identity renames, and errors, with a sensiblechangedflag and message. TheFIXME: send signalnote clearly marks the future enhancement without affecting current correctness.src/dbus/filesystem/mod.rs (1)
152-178: Unregister path could also avoid fail‑fast behavior (optional).
unregister_filesystemfails immediately on the firstFilesystemR*::unregistererror, which can leave some interfaces registered while the manager mapping has already been removed. As a follow‑up, you might want to attempt all unregister calls, log individual failures, and only then decide whether to return an error.src/dbus/blockdev/mod.rs (1)
150-175: Unregister path may want to tolerate individual interface removal failures.
unregister_blockdevfails on the first unsuccessfulBlockdevR*::unregisterbefore cleaning up later revisions or the manager mapping. As you start using this function, it may be safer to attempt all unregisters, log any failures, and only then decide whether to propagate an error.src/dbus/filesystem/filesystem_3_7/mod.rs (2)
137-141: Consider markingoriginproperty as const.The
originproperty represents the source filesystem UUID for snapshots, which is set at creation time and never changes. Consider addingemits_changed_signal = "const"to match other immutable properties likecreated,pool, anduuid.- #[zbus(property)] + #[zbus(property(emits_changed_signal = "const"))] #[allow(non_snake_case)] async fn origin(&self) -> Result<(bool, FilesystemUuid), Error> {
131-135: Consider addingemits_changed_signalfor thenameproperty.Since the
SetNamemethod can modify the filesystem name, thenameproperty should likely emit a change signal. Consideremits_changed_signal = "true"or"invalidates"to notify D-Bus clients when the name changes.- #[zbus(property)] + #[zbus(property(emits_changed_signal = "invalidates"))] #[allow(non_snake_case)] async fn name(&self) -> Result<Name, Error> {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (35)
Cargo.toml(2 hunks)src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_8/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/engine/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (10)
- src/dbus/blockdev/blockdev_3_0/methods.rs
- src/dbus/blockdev/blockdev_3_3/props.rs
- src/dbus/filesystem/filesystem_3_6/props.rs
- src/dbus/filesystem/filesystem_3_0/props.rs
- src/dbus/blockdev/blockdev_3_0/props.rs
- src/dbus/filesystem/filesystem_3_7/props.rs
- src/dbus/mod.rs
- src/dbus/blockdev/blockdev_3_5/mod.rs
- src/dbus/pool/mod.rs
- src/dbus/filesystem/filesystem_3_2/mod.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-01T22:14:23.564Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.564Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/filesystem_3_6/mod.rssrc/dbus/filesystem/filesystem_3_0/methods.rssrc/dbus/filesystem/filesystem_3_1/mod.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/blockdev/mod.rssrc/dbus/filesystem/filesystem_3_5/mod.rssrc/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_4/mod.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/filesystem/filesystem_3_9/mod.rssrc/dbus/blockdev/blockdev_3_7/mod.rssrc/dbus/filesystem/filesystem_3_8/mod.rssrc/dbus/filesystem/filesystem_3_7/mod.rssrc/dbus/blockdev/shared.rssrc/dbus/filesystem/shared.rssrc/dbus/blockdev/blockdev_3_0/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/blockdev/mod.rssrc/dbus/blockdev/blockdev_3_3/mod.rssrc/dbus/blockdev/blockdev_3_7/mod.rssrc/dbus/blockdev/shared.rssrc/dbus/filesystem/shared.rssrc/dbus/blockdev/blockdev_3_0/mod.rs
🧬 Code graph analysis (16)
src/dbus/filesystem/filesystem_3_6/mod.rs (3)
src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-39)size_limit_prop(14-19)src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)
src/dbus/blockdev/blockdev_3_1/mod.rs (11)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(28-44)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_2/mod.rs (14)
new(34-46)uuid(122-124)register(48-60)connection(66-68)unregister(62-71)set_user_info(78-80)devnode(84-86)hardware_info(90-98)user_info(102-104)initialization_time(108-112)pool(116-118)tier(128-130)physical_path(134-142)total_physical_size(146-154)src/dbus/blockdev/blockdev_3_3/mod.rs (13)
new(42-54)uuid(137-139)register(56-68)connection(74-76)unregister(70-79)devnode(86-88)hardware_info(92-100)user_info(104-106)initialization_time(123-127)pool(131-133)tier(143-145)physical_path(149-157)total_physical_size(161-169)src/dbus/blockdev/blockdev_3_4/mod.rs (13)
new(39-51)uuid(134-136)register(53-65)connection(71-73)unregister(67-76)devnode(83-85)hardware_info(89-97)user_info(101-103)initialization_time(120-124)pool(128-130)tier(140-142)physical_path(146-154)total_physical_size(158-166)src/dbus/blockdev/blockdev_3_5/mod.rs (13)
new(39-51)uuid(134-136)register(53-65)connection(71-73)unregister(67-76)devnode(83-85)hardware_info(89-97)user_info(101-103)initialization_time(120-124)pool(128-130)tier(140-142)physical_path(146-154)total_physical_size(158-166)src/dbus/blockdev/blockdev_3_6/mod.rs (13)
new(40-52)uuid(135-137)register(54-66)connection(72-74)unregister(68-77)devnode(84-86)hardware_info(90-98)user_info(102-104)initialization_time(121-125)pool(129-131)tier(141-143)physical_path(147-155)total_physical_size(159-167)src/dbus/blockdev/blockdev_3_7/mod.rs (13)
new(40-52)uuid(135-137)register(54-66)connection(72-74)unregister(68-77)devnode(84-86)hardware_info(90-98)user_info(102-104)initialization_time(121-125)pool(129-131)tier(141-143)physical_path(147-155)total_physical_size(159-167)src/dbus/blockdev/blockdev_3_8/mod.rs (13)
new(39-51)uuid(134-136)register(53-65)connection(71-73)unregister(67-76)devnode(83-85)hardware_info(89-97)user_info(101-103)initialization_time(120-124)pool(128-130)tier(140-142)physical_path(146-154)total_physical_size(158-166)src/dbus/blockdev/blockdev_3_9/mod.rs (13)
new(39-51)uuid(134-136)register(53-65)connection(71-73)unregister(67-76)devnode(83-85)hardware_info(89-97)user_info(101-103)initialization_time(120-124)pool(128-130)tier(140-142)physical_path(146-154)total_physical_size(158-166)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
src/engine/strat_engine/thinpool/filesystem.rs (1)
format(156-162)
src/dbus/filesystem/filesystem_3_1/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (11)
new(34-46)uuid(123-125)register(48-60)unregister(62-71)name(99-101)set_name(81-83)created(87-89)devnode(93-95)pool(105-107)size(111-113)used(117-119)
src/dbus/filesystem/filesystem_3_5/mod.rs (12)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (12)
new(34-46)uuid(123-125)register(48-60)connection(66-68)unregister(62-71)name(99-101)set_name(81-83)created(87-89)devnode(93-95)pool(105-107)size(111-113)used(117-119)src/dbus/filesystem/filesystem_3_1/mod.rs (12)
new(38-50)uuid(127-129)register(52-64)connection(70-72)unregister(66-75)name(103-105)set_name(85-87)created(91-93)devnode(97-99)pool(109-111)size(115-117)used(121-123)src/dbus/filesystem/filesystem_3_2/mod.rs (12)
new(38-50)uuid(127-129)register(52-64)connection(70-72)unregister(66-75)name(103-105)set_name(85-87)created(91-93)devnode(97-99)pool(109-111)size(115-117)used(121-123)src/dbus/filesystem/filesystem_3_3/mod.rs (12)
new(38-50)uuid(126-128)register(52-64)connection(70-72)unregister(66-75)name(103-105)set_name(85-87)created(91-93)devnode(97-99)pool(108-110)size(114-116)used(120-122)src/dbus/filesystem/filesystem_3_4/mod.rs (12)
new(38-50)uuid(127-129)register(52-64)connection(70-72)unregister(66-75)name(103-105)set_name(85-87)created(91-93)devnode(97-99)pool(109-111)size(115-117)used(121-123)src/dbus/filesystem/filesystem_3_6/mod.rs (12)
new(41-53)uuid(149-151)register(55-67)connection(73-75)unregister(69-78)name(106-108)set_name(88-90)created(94-96)devnode(100-102)pool(112-114)size(118-120)used(143-145)src/dbus/filesystem/filesystem_3_7/mod.rs (12)
new(43-55)uuid(182-184)register(57-69)connection(75-77)unregister(71-80)name(133-135)set_name(90-92)created(96-98)devnode(102-104)pool(145-147)size(151-153)used(176-178)src/dbus/filesystem/filesystem_3_8/mod.rs (12)
new(40-52)uuid(179-181)register(54-66)connection(72-74)unregister(68-77)name(130-132)set_name(87-89)created(93-95)devnode(99-101)pool(142-144)size(148-150)used(173-175)src/dbus/filesystem/filesystem_3_9/mod.rs (12)
new(40-52)uuid(179-181)register(54-66)connection(72-74)unregister(68-77)name(130-132)set_name(87-89)created(93-95)devnode(99-101)pool(142-144)size(148-150)used(173-175)
src/dbus/blockdev/blockdev_3_8/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)
src/dbus/blockdev/blockdev_3_2/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/pool/mod.rs (1)
pool(71-71)
src/dbus/filesystem/filesystem_3_3/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/dbus/filesystem/filesystem_3_0/mod.rs (9)
new(34-46)uuid(123-125)name(99-101)set_name(81-83)created(87-89)devnode(93-95)pool(105-107)size(111-113)used(117-119)
src/dbus/blockdev/blockdev_3_6/mod.rs (3)
src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)
src/dbus/blockdev/blockdev_3_9/mod.rs (4)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_0/mod.rs (13)
new(38-50)uuid(126-128)register(52-64)connection(70-72)unregister(66-75)devnode(88-90)hardware_info(94-102)user_info(106-108)initialization_time(112-116)pool(120-122)tier(132-134)physical_path(138-146)total_physical_size(150-158)src/dbus/blockdev/blockdev_3_3/mod.rs (15)
new(42-54)uuid(137-139)register(56-68)connection(74-76)unregister(70-79)devnode(86-88)hardware_info(92-100)user_info(104-106)set_UserInfo(110-119)initialization_time(123-127)pool(131-133)tier(143-145)physical_path(149-157)total_physical_size(161-169)new_physical_size(173-181)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)
src/dbus/filesystem/filesystem_3_8/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-39)size_limit_prop(14-19)src/dbus/filesystem/filesystem_3_7/props.rs (3)
merge_scheduled_prop(23-25)origin_prop(14-21)set_merge_scheduled_prop(27-38)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)
src/dbus/filesystem/filesystem_3_7/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-39)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_7/props.rs (3)
merge_scheduled_prop(23-25)origin_prop(14-21)set_merge_scheduled_prop(27-38)
src/dbus/blockdev/shared.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (2)
uuid(126-128)tier(132-134)src/dbus/blockdev/blockdev_3_1/mod.rs (2)
uuid(122-124)tier(128-130)src/dbus/blockdev/blockdev_3_2/mod.rs (2)
uuid(122-124)tier(128-130)src/dbus/blockdev/blockdev_3_3/mod.rs (2)
uuid(137-139)tier(143-145)src/dbus/blockdev/blockdev_3_4/mod.rs (2)
uuid(134-136)tier(140-142)src/dbus/blockdev/blockdev_3_5/mod.rs (2)
uuid(134-136)tier(140-142)src/dbus/blockdev/blockdev_3_6/mod.rs (2)
uuid(135-137)tier(141-143)src/dbus/blockdev/blockdev_3_7/mod.rs (2)
uuid(135-137)tier(141-143)src/dbus/blockdev/blockdev_3_8/mod.rs (2)
uuid(134-136)tier(140-142)src/dbus/blockdev/blockdev_3_9/mod.rs (2)
uuid(134-136)tier(140-142)
src/dbus/filesystem/shared.rs (11)
src/dbus/pool/pool_3_9/mod.rs (1)
Name(104-106)src/dbus/filesystem/filesystem_3_0/mod.rs (2)
uuid(123-125)name(99-101)src/dbus/filesystem/filesystem_3_1/mod.rs (2)
uuid(127-129)name(103-105)src/dbus/filesystem/filesystem_3_2/mod.rs (2)
uuid(127-129)name(103-105)src/dbus/filesystem/filesystem_3_3/mod.rs (2)
uuid(126-128)name(103-105)src/dbus/filesystem/filesystem_3_4/mod.rs (2)
uuid(127-129)name(103-105)src/dbus/filesystem/filesystem_3_5/mod.rs (2)
uuid(127-129)name(103-105)src/dbus/filesystem/filesystem_3_6/mod.rs (2)
uuid(149-151)name(106-108)src/dbus/filesystem/filesystem_3_7/mod.rs (2)
uuid(182-184)name(133-135)src/dbus/filesystem/filesystem_3_8/mod.rs (2)
uuid(179-181)name(130-132)src/dbus/filesystem/filesystem_3_9/mod.rs (2)
uuid(179-181)name(130-132)
src/dbus/blockdev/blockdev_3_0/mod.rs (4)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(28-44)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (7)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)user_info_prop(51-53)src/dbus/pool/mod.rs (1)
pool(71-71)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (33)
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: stratis-min-cli-checks
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: python-based-tests
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile stratisd-tools, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
🔇 Additional comments (30)
src/engine/mod.rs (1)
18-20: Re-exporting lock guards is appropriateMaking
SomeLockReadGuardandSomeLockWriteGuardpublic alongside the other guard types matches their new usage in shared helpers and keeps the engine surface coherent.Cargo.toml (1)
233-243: Double‑check git-based zbus/zvariant setup and zvariant gatingThe zbus/zvariant dependencies are pinned to a personal git repo/branch and
zvariantis now always enabled (non‑optional), whiledbus_enabledonly togglesdep:zbus. That’s fine short‑term, but for long‑term maintenance you may want to:
- Confirm this fork/branch is the intended source for master, and plan how you'll track upstream updates.
- Consider making
zvariantoptional and adding"dep:zvariant"todbus_enabledif it’s only used in the D-Bus path, so non‑D-Bus builds avoid pulling it in.Also applies to: 298-299
src/dbus/blockdev/blockdev_3_1/mod.rs (2)
26-72: BlockdevR1 struct and lifecycle helpers match existing patternThe
BlockdevR1fields andnew/register/unregisterfunctions mirror the other blockdev revisions, correctly cloning the manager and usingobject_server().at/removefor binding, so the lifecycle integration looks sound.
74-155: BlockdevR1 interface correctly reuses shared blockdev helpersAll properties and
set_user_infodelegate throughblockdev_prop,pool_prop, andset_user_info_method, matching the patterns in R2–R9 and centralizing pool/blockdev lookup and error handling. This should give consistent behavior across blockdev interface versions.src/dbus/filesystem/shared.rs (1)
13-30: Filesystem shared helpers are well-factored and symmetric with blockdev
set_filesystem_propandfilesystem_propcleanly centralize pool lookup, missing‑pool/filesystem error reporting, and guard handling, mirroring the existing blockdev shared helpers. This reduces duplication in the per‑revision filesystem modules and keeps behavior consistent.Also applies to: 32-50
src/dbus/blockdev/blockdev_3_8/mod.rs (2)
31-77: BlockdevR8 struct and registration/unregistration are consistentThe
BlockdevR8struct fields and itsregister/unregisterfunctions follow the same pattern as the other blockdev revisions, so the Manager wiring and D-Bus object lifecycle look consistent.
79-179: UserInfo/NewPhysicalSize wiring correctly reuses shared helpersThe interface delegates all getters through
blockdev_propand the R0/R3 prop functions, whileset_UserInfousesset_blockdev_propwithset_user_info_prop, andnew_physical_sizeusesnew_physical_size_prop. This keeps R8’s behavior aligned with the existing blockdev versions while exposing the additional properties.src/dbus/blockdev/blockdev_3_2/mod.rs (2)
26-72: BlockdevR2 struct and lifecycle helper pattern look goodThe
BlockdevR2state (engine, manager, parent_uuid, uuid) and itsnew/register/unregistermethods are consistent with the other blockdev revisions and provide the expected D-Bus object lifecycle hooks.
74-155: BlockdevR2 interface cleanly reuses shared methods and props
set_user_infoforwards toset_user_info_method, and all properties useblockdev_prop/pool_propplus the R0 prop helpers, so behavior and error handling should match R0/R3–R9 for the shared pieces.src/dbus/blockdev/blockdev_3_7/mod.rs (2)
32-78: BlockdevR7 struct and D-Bus lifecycle match other revisionsThe
BlockdevR7struct makeup and itsregister/unregistermethods follow the same pattern as the surrounding blockdev versions, so the engine/manager wiring and object lifetime are consistent.
80-179: BlockdevR7 interface wiring is consistent and introduces mutable UserInfo cleanlyThe getters all go through
blockdev_propand the shared prop functions, whileset_UserInfousesset_blockdev_propwithset_user_info_prop, mirroring the R8 design and providing a straightforward mutableUserInfoproperty alongsidenew_physical_size.src/dbus/blockdev/shared.rs (1)
13-26: Shared blockdev helpers correctly separate setter/getter error types.
set_blockdev_propuseszbus::Errorfor the setter path whileblockdev_propuseszbus::fdo::Errorfor read‑only properties, matching the pattern in filesystem helpers and the PR requirement for setters. Error messages and UUID usage look correct.Also applies to: 28-44
src/dbus/filesystem/filesystem_3_0/mod.rs (1)
26-31: FilesystemR0 interface is consistent with shared helpers and other revisions.Registration/unregistration and all properties use the expected helpers and
zbus::fdo::Errorfor getters, with no setters in this revision, so this module aligns with the intended pattern.Also applies to: 48-72, 74-125
src/dbus/filesystem/filesystem_3_5/mod.rs (1)
30-35: FilesystemR5 mirrors R0 correctly.Structure, registration, and property wiring match FilesystemR0, with getters using
fdo::Errorand no property setters, which is consistent with the overall design.Also applies to: 37-76, 78-129
src/dbus/filesystem/filesystem_3_6/mod.rs (1)
122-139: SizeLimit setter correctly returnszbus::Error.
set_SizeLimitusesResult<(), zbus::Error>and delegates toset_filesystem_prop/set_size_limit_prop, which also returnzbus::Error, matching the PR requirement while keeping getters onfdo::Error.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
79-117: BlockdevR4 user‑info setter uses the correct error type.
set_UserInforeturnsResult<(), zbus::Error>and routes throughset_blockdev_prop/set_user_info_prop, keeping getters onfdo::Errorwhile satisfying the requirement that property setters usezbus::Error. The rest of the properties are wired consistently with other blockdev revisions.src/dbus/filesystem/filesystem_3_1/mod.rs (1)
30-130: LGTM! Clean implementation following established patterns.The FilesystemR1 interface implementation correctly delegates to shared helpers, uses appropriate error types, and follows the architectural pattern established by FilesystemR0 and other revisions.
src/dbus/filesystem/filesystem_3_4/mod.rs (1)
30-130: LGTM! Consistent implementation for R4 interface.FilesystemR4 follows the same pattern as R1, which is appropriate for API versioning. The interface exposes
org.storage.stratis3.filesystem.r4with standard filesystem properties and delegates correctly to shared helpers.src/dbus/filesystem/filesystem_3_9/mod.rs (1)
32-182: LGTM! Property setters correctly return zbus::Error.The FilesystemR9 implementation properly handles mutable properties (MergeScheduled and SizeLimit) with setters that return
zbus::Error, aligning with the PR objective mentioned in comments. The delegation to shared helpers from filesystem_3_0, filesystem_3_6, and filesystem_3_7 is appropriate.src/dbus/blockdev/blockdev_3_9/mod.rs (1)
31-179: LGTM! Correctly implements BlockdevR9 interface.The implementation properly delegates to shared blockdev properties and the set_UserInfo setter returns
zbus::Erroras required. Property emission signals are appropriately configured for the block device semantics.src/dbus/blockdev/blockdev_3_0/mod.rs (1)
30-159: LGTM! BlockdevR0 implementation is solid.The R0 interface correctly exposes block device properties and the SetUserInfo method. Past review comments about pool property and error messages have been addressed. The implementation properly delegates to shared helpers and uses appropriate emission signals.
src/dbus/filesystem/filesystem_3_8/mod.rs (1)
32-182: LGTM! FilesystemR8 properly implements mutable properties.The implementation correctly handles property setters (set_MergeScheduled and set_SizeLimit) with the required
zbus::Errorreturn type, and appropriately delegates to shared filesystem property helpers.src/dbus/filesystem/filesystem_3_7/mod.rs (8)
1-29: Imports and license header look correct.The imports appropriately distinguish between
zbus::fdo::Error(aliased asErrorfor property getters) andzbus::Error(used explicitly for property setters), aligning with the PR requirement that property setters must returnzbus::Error.
31-33: Module structure follows established pattern.The re-exports align with other filesystem revision modules, providing a clean public API for the prop helpers.
35-55: Struct definition and private constructor are well-designed.The private constructor pattern with public
registermethod enforces proper D-Bus lifecycle management.
57-81: Lifecycle methods follow established pattern.The
registerandunregistermethods properly propagate errors viaStratisResult. Based on learnings, the orchestration layer (e.g.,register_filesystem) handles these errors gracefully by logging warnings and continuing with remaining interfaces rather than failing the entire operation.
83-92: D-Bus interface definition looks correct.The interface name follows the versioning convention, and
set_nameproperly delegates to the shared method helper.
118-129: Property setter correctly returnszbus::Error.The
set_MergeScheduledsetter returnsResult<(), zbus::Error>as required, matching the PR comment requirement that property setters must returnzbus::Errorinstead ofzbus::fdo::Error.
161-172: Property setter correctly returnszbus::Error.The
set_SizeLimitsetter returnsResult<(), zbus::Error>, consistent withset_MergeScheduledand the PR requirements.
180-184: LGTM -uuidproperty is correctly synchronous.The
uuidproperty appropriately uses a synchronous function since it simply returns the stored value without any async operations.
Signed-off-by: mulhern <[email protected]>
Signed-off-by: mulhern <[email protected]>
mulkieran
force-pushed
the
blockdev-changes
branch
from
d8b6907 to
b8c7cbb
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (4)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
7-11: Missing import forhandle_action!macro.The
handle_action!macro is used at line 29 but not imported. This will cause a compilation error.use crate::{ dbus::{consts::OK_STRING, types::DbusErrorEnum}, engine::{Engine, FilesystemUuid, PoolIdentifier, PoolUuid, RenameAction}, + handle_action, stratis::StratisError, };src/dbus/filesystem/mod.rs (1)
58-147: Fail-fast registration contradicts PR design intent.Per PR objectives, "the registration process should not error rapidly if one interface fails during registration." The current implementation uses
?operators that fail-fast, preventing subsequent interface registrations and leaving previously registered interfaces orphaned on the D-Bus object server.Based on learnings, registration failures should log warnings and continue processing rather than failing the entire operation.
src/dbus/blockdev/mod.rs (1)
56-145: Fail-fast registration contradicts PR design intent.Per PR objectives, "the registration process should not error rapidly if one interface fails during registration." The current implementation uses
?operators that fail-fast on the first error, preventing subsequent interface registrations and leaving previously registered interfaces (e.g., BlockdevR0-R4 if R5 fails) orphaned on the D-Bus object server.Based on learnings, registration failures should log warnings and continue processing rather than failing the entire operation.
src/dbus/blockdev/blockdev_3_3/mod.rs (1)
100-105: UserInfo emits_changed_signal remains inconsistent across blockdev revisions
BlockdevR2.user_infois explicitly markedemits_changed_signal = "false", whileBlockdevR3(here) and the newerBlockdevR4/BlockdevR9rely on the default, leading to different notification behavior for the same conceptual property. If this wasn’t an intentional behavioral change, consider aligninguser_infowith R2 by addingemits_changed_signal = "false"(and adjusting R4/R9 similarly), or documenting the divergence.Example for Line 100:
- #[zbus(property)] + #[zbus(property(emits_changed_signal = "false"))] async fn user_info(&self) -> Result<(bool, String), Error> {
🧹 Nitpick comments (1)
src/dbus/blockdev/blockdev_3_5/mod.rs (1)
79-168: R5 properties and setter wiring are consistent; consider deduplicating with R7.The property getters and
set_user_infoare wired identically to R7, with appropriate use of shared helpers andzbus::Errorfor the setter, so behavior and error typing look correct. Since the R5 and R7 interface implementations are effectively the same apart from type/interface names, you might eventually factor the common logic into a generic helper or macro to reduce duplication and ease future maintenance, though this is optional and can be deferred.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (35)
Cargo.toml(2 hunks)src/dbus/blockdev/blockdev_3_0/methods.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_0/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_1/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_2/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_3/props.rs(1 hunks)src/dbus/blockdev/blockdev_3_4/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_5/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_6/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_7/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_8/mod.rs(1 hunks)src/dbus/blockdev/blockdev_3_9/mod.rs(1 hunks)src/dbus/blockdev/mod.rs(1 hunks)src/dbus/blockdev/shared.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/methods.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_0/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_1/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_2/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_3/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_4/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_5/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_6/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_7/props.rs(1 hunks)src/dbus/filesystem/filesystem_3_8/mod.rs(1 hunks)src/dbus/filesystem/filesystem_3_9/mod.rs(1 hunks)src/dbus/filesystem/mod.rs(1 hunks)src/dbus/filesystem/shared.rs(1 hunks)src/dbus/mod.rs(1 hunks)src/dbus/pool/mod.rs(1 hunks)src/engine/mod.rs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (10)
- src/dbus/blockdev/blockdev_3_0/methods.rs
- src/dbus/blockdev/shared.rs
- src/dbus/pool/mod.rs
- src/dbus/blockdev/blockdev_3_0/props.rs
- src/dbus/filesystem/filesystem_3_4/mod.rs
- src/dbus/blockdev/blockdev_3_1/mod.rs
- src/dbus/blockdev/blockdev_3_6/mod.rs
- src/dbus/mod.rs
- src/dbus/filesystem/filesystem_3_6/props.rs
- src/dbus/filesystem/filesystem_3_7/mod.rs
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-01T22:14:23.564Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3927
File: src/dbus/pool/pool_3_6/methods.rs:88-100
Timestamp: 2025-12-01T22:14:23.564Z
Learning: In src/dbus/pool/pool_3_6/methods.rs and similar D-Bus pool methods, when filesystem registration fails after successful creation, the code intentionally logs a warning and continues processing remaining filesystems rather than failing the entire operation. This allows the method to return success even if some filesystems aren't visible on D-Bus, which is the desired behavior.
Applied to files:
src/dbus/filesystem/mod.rssrc/dbus/filesystem/filesystem_3_7/props.rssrc/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/filesystem/filesystem_3_5/mod.rssrc/dbus/blockdev/mod.rssrc/dbus/filesystem/filesystem_3_0/props.rssrc/dbus/filesystem/filesystem_3_6/mod.rssrc/dbus/filesystem/filesystem_3_9/mod.rssrc/dbus/filesystem/filesystem_3_8/mod.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/filesystem/filesystem_3_0/methods.rssrc/dbus/filesystem/shared.rssrc/dbus/blockdev/blockdev_3_7/mod.rssrc/dbus/filesystem/filesystem_3_0/mod.rssrc/dbus/filesystem/filesystem_3_2/mod.rssrc/dbus/filesystem/filesystem_3_1/mod.rs
📚 Learning: 2025-08-20T02:37:22.477Z
Learnt from: jbaublitz
Repo: stratis-storage/stratisd PR: 3651
File: src/dbus_api/pool/pool_3_9/methods.rs:173-176
Timestamp: 2025-08-20T02:37:22.477Z
Learning: The encrypt_pool, reencrypt_pool, and decrypt_pool methods in src/dbus_api/pool/pool_3_9/methods.rs have intentionally different lock handling patterns due to different workflow requirements, and this is not an inconsistency that needs to be fixed.
Applied to files:
src/dbus/filesystem/filesystem_3_3/mod.rssrc/dbus/blockdev/mod.rssrc/dbus/filesystem/filesystem_3_0/props.rssrc/dbus/blockdev/blockdev_3_0/mod.rssrc/dbus/filesystem/shared.rssrc/dbus/blockdev/blockdev_3_7/mod.rs
🧬 Code graph analysis (18)
src/dbus/blockdev/blockdev_3_3/props.rs (2)
src/dbus/blockdev/blockdev_3_0/mod.rs (2)
user_info(102-104)pool(114-116)src/dbus/pool/mod.rs (1)
pool(71-71)
src/dbus/blockdev/blockdev_3_3/mod.rs (6)
src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/stratis/keys.rs (1)
engine(28-46)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_0/mod.rs (14)
new(38-50)uuid(119-121)register(52-64)connection(70-72)unregister(66-75)devnode(86-88)hardware_info(91-99)user_info(102-104)set_user_info(81-83)initialization_time(107-111)pool(114-116)tier(124-126)physical_path(129-137)total_physical_size(140-148)src/dbus/blockdev/blockdev_3_2/mod.rs (14)
new(34-46)uuid(115-117)register(48-60)connection(66-68)unregister(62-71)devnode(82-84)hardware_info(87-95)user_info(98-100)set_user_info(77-79)initialization_time(103-107)pool(110-112)tier(120-122)physical_path(125-133)total_physical_size(136-144)src/dbus/pool/mod.rs (1)
pool(71-71)
src/dbus/filesystem/filesystem_3_3/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/filesystem/filesystem_3_5/mod.rs (1)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)
src/dbus/blockdev/mod.rs (10)
src/dbus/blockdev/blockdev_3_0/mod.rs (4)
connection(70-72)register(52-64)unregister(66-75)uuid(119-121)src/dbus/blockdev/blockdev_3_1/mod.rs (4)
connection(66-68)register(48-60)unregister(62-71)uuid(115-117)src/dbus/blockdev/blockdev_3_2/mod.rs (4)
connection(66-68)register(48-60)unregister(62-71)uuid(115-117)src/dbus/blockdev/blockdev_3_3/mod.rs (4)
connection(74-76)register(56-68)unregister(70-79)uuid(130-132)src/dbus/blockdev/blockdev_3_4/mod.rs (4)
connection(71-73)register(53-65)unregister(67-76)uuid(127-129)src/dbus/blockdev/blockdev_3_5/mod.rs (4)
connection(71-73)register(53-65)unregister(67-76)uuid(127-129)src/dbus/blockdev/blockdev_3_6/mod.rs (4)
connection(72-74)register(54-66)unregister(68-77)uuid(129-131)src/dbus/blockdev/blockdev_3_7/mod.rs (4)
connection(72-74)register(54-66)unregister(68-77)uuid(128-130)src/dbus/blockdev/blockdev_3_8/mod.rs (4)
connection(71-73)register(53-65)unregister(67-76)uuid(127-129)src/dbus/blockdev/blockdev_3_9/mod.rs (4)
connection(71-73)register(53-65)unregister(67-76)uuid(127-129)
src/dbus/filesystem/filesystem_3_0/props.rs (1)
src/dbus/pool/shared.rs (1)
pool_prop(21-29)
src/dbus/filesystem/filesystem_3_6/mod.rs (2)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)
src/dbus/filesystem/filesystem_3_9/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/pool_3_0/props.rs (3)
name_prop(12-15)size_prop(17-19)used_prop(21-27)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/blockdev/blockdev_3_4/mod.rs (4)
src/dbus/blockdev/blockdev_3_0/props.rs (6)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)src/dbus/blockdev/blockdev_3_0/mod.rs (10)
new(38-50)uuid(119-121)devnode(86-88)hardware_info(91-99)user_info(102-104)set_user_info(81-83)initialization_time(107-111)pool(114-116)tier(124-126)physical_path(129-137)
src/dbus/filesystem/filesystem_3_8/mod.rs (5)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_6/props.rs (2)
set_size_limit_prop(21-39)size_limit_prop(14-19)src/dbus/filesystem/shared.rs (2)
filesystem_prop(32-50)set_filesystem_prop(13-30)src/dbus/filesystem/filesystem_3_7/mod.rs (13)
new(43-55)uuid(169-171)register(57-69)connection(75-77)unregister(71-80)name(127-129)created(94-96)devnode(99-101)pool(137-139)size(142-144)size_limit(147-149)set_size_limit(152-161)used(164-166)src/dbus/filesystem/filesystem_3_9/mod.rs (13)
new(40-52)uuid(166-168)register(54-66)connection(72-74)unregister(68-77)name(124-126)created(91-93)devnode(96-98)pool(134-136)size(139-141)size_limit(144-146)set_size_limit(149-158)used(161-163)
src/dbus/blockdev/blockdev_3_0/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(28-44)src/dbus/blockdev/blockdev_3_0/methods.rs (1)
set_user_info_method(13-53)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)
src/dbus/filesystem/filesystem_3_0/methods.rs (1)
src/dbus/filesystem/filesystem_3_0/mod.rs (3)
uuid(115-117)name(95-97)pool(100-102)
src/dbus/blockdev/blockdev_3_7/mod.rs (3)
src/dbus/blockdev/shared.rs (1)
blockdev_prop(28-44)src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)
src/dbus/filesystem/filesystem_3_0/mod.rs (4)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/pool/shared.rs (1)
pool_prop(21-29)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)src/engine/engine.rs (6)
created(84-84)devnode(81-81)devnode(106-106)size(93-93)size(122-122)used(90-90)
src/dbus/filesystem/filesystem_3_2/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/blockdev/blockdev_3_9/mod.rs (3)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/dbus/blockdev/blockdev_3_3/props.rs (2)
new_physical_size_prop(12-17)set_user_info_prop(19-40)
src/dbus/filesystem/filesystem_3_1/mod.rs (3)
src/dbus/filesystem/filesystem_3_0/props.rs (6)
created_prop(15-17)devnode_prop(19-28)name_prop(30-32)pool_prop(34-46)size_prop(48-50)used_prop(52-54)src/dbus/filesystem/filesystem_3_0/methods.rs (1)
set_name_method(13-50)src/dbus/filesystem/shared.rs (1)
filesystem_prop(32-50)
src/dbus/blockdev/blockdev_3_8/mod.rs (4)
src/dbus/blockdev/blockdev_3_0/props.rs (8)
devnode_prop(13-15)hardware_info_prop(17-19)init_time_prop(21-23)physical_path_prop(25-27)pool_prop(29-41)tier_prop(47-49)total_physical_size_prop(43-45)user_info_prop(51-53)src/dbus/blockdev/shared.rs (2)
blockdev_prop(28-44)set_blockdev_prop(13-26)src/stratis/keys.rs (1)
engine(28-46)src/dbus/pool/mod.rs (1)
pool(71-71)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (32)
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: testing-farm:fedora-rawhide-x86_64:cockpit
- GitHub Check: testing-farm:fedora-rawhide-x86_64:local
- GitHub Check: testing-farm:fedora-42-x86_64:local
- GitHub Check: testing-farm:fedora-41-x86_64:local
- GitHub Check: testing-farm:fedora-43-x86_64:local
- GitHub Check: rpm-build:fedora-42-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-rawhide-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-41-x86_64:copr_pull
- GitHub Check: rpm-build:fedora-43-x86_64:copr_pull
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile docs-ci, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min-no-systemd, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-utils, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: tests-with-testing-repo (master)
- GitHub Check: python-based-tests
- GitHub Check: stratis-min-cli-checks
- GitHub Check: checks (make -f Makefile build-min, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile test, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile build-no-ipc, 1.91.0, cargo)
- GitHub Check: checks (PROFILEDIR=debug make -f Makefile build, 1.91.0, cargo)
- GitHub Check: checks (make -f Makefile clippy, 1.91.0, clippy)
- GitHub Check: checks_with_udev (RUST_LOG=stratisd=debug make -f Makefile test-loop-root, 1.91.0, cargo)
- GitHub Check: checks_with_tang_should_fail (TANG_URL=localhost make -f Makefile test-clevis-loop-should-fail-ro...
🔇 Additional comments (21)
Cargo.toml (1)
298-298: Feature flag migration looks correct.The
dbus_enabledfeature now correctly depends ondep:zbus, aligning with the dependency migration.src/engine/mod.rs (1)
18-20: LGTM!The addition of
SomeLockReadGuardandSomeLockWriteGuardto the public exports correctly supports the new guard-based access patterns used in the D-Bus property setters and shared utilities across the PR.src/dbus/filesystem/filesystem_3_7/props.rs (1)
1-37: LGTM!The property handlers are well-structured:
origin_propandmerge_scheduled_propfollow established patterns for read-only props.set_merge_scheduled_propcorrectly returnszbus::Error(notzbus::fdo::Error) per PR requirements, and properly maps bothNewValueandIdentityoutcomes toOk(()).src/dbus/filesystem/shared.rs (2)
13-30: LGTM!The
set_filesystem_prophelper correctly useszbus::Error(notzbus::fdo::Error) for the return type, aligning with the PR requirement that property setters must returnzbus::Error.
32-49: LGTM!The
filesystem_propread helper appropriately useszbus::fdo::Errorfor property getters, which is the standard D-Bus FDO error type for read operations. The implementation correctly handles both missing pool and missing filesystem cases.src/dbus/filesystem/filesystem_3_0/methods.rs (1)
13-49: Implementation follows established patterns.The
set_name_methodfunction correctly handles allRenameActionvariants and follows the codebase's D-Bus method return tuple convention((result), error_code, message). The FIXME comment at line 36 for signal emission is noted as intentional deferred work.src/dbus/blockdev/blockdev_3_3/props.rs (2)
12-17: LGTM!The
new_physical_size_propcorrectly usesoption_to_tupleto handle the optional size value, converting bytes to string representation.
19-39: LGTM!The
set_user_info_propimplementation:
- Correctly returns
zbus::Errorper PR requirements for property setters.- Implements an identity check optimization to avoid unnecessary pool mutations when the value is unchanged.
- Properly handles the error cases for missing blockdev and pool operation failures.
src/dbus/filesystem/filesystem_3_5/mod.rs (2)
30-75: LGTM!The
FilesystemR5struct and its lifecycle methods (register/unregister) follow the established pattern for D-Bus interface registration. The registration returning an error is appropriate at this level—the "don't fail rapidly" concern from PR comments applies to higher-level orchestration that calls multiple interface registrations.
78-121: LGTM!The D-Bus interface implementation correctly:
- Exposes the
org.storage.stratis3.filesystem.r5interface.- Delegates property accessors to shared helpers from
filesystem_3_0.- Uses appropriate
emits_changed_signalannotations for properties (constfor immutable,invalidatesfor devnode, default for mutable).- Returns
zbus::fdo::Errorfor property getters, which is the correct error type for read operations.src/dbus/blockdev/blockdev_3_4/mod.rs (1)
31-77: BlockdevR4 D-Bus surface and helpers look consistent and correctStruct layout, register/unregister, and all properties cleanly delegate via
blockdev_prop/set_blockdev_propand shared props; error types andemits_changed_signalflags match the patterns used in neighboring revisions.Also applies to: 79-168
src/dbus/filesystem/filesystem_3_9/mod.rs (1)
32-77: FilesystemR9 wiring matches prior revisions and uses the correct error typesConstructor, register/unregister, and all properties/mutators follow the established filesystem patterns; delegation through
filesystem_prop/set_filesystem_propand use ofResult<(), zbus::Error>for setters look correct.Also applies to: 80-169
src/dbus/blockdev/blockdev_3_9/mod.rs (1)
31-77: BlockdevR9 implementation is consistent with other blockdev revisionsStruct fields, registration helpers, and property/setter wiring mirror R0/R2/R3/R4 and correctly reuse
blockdev_prop,set_blockdev_prop, and the shared prop functions; no issues stand out.Also applies to: 79-168
src/dbus/blockdev/blockdev_3_0/mod.rs (1)
21-76: BlockdevR0 base interface and helpers look solidExports, constructor, register/unregister, and property implementations are coherent and form a good base for the higher blockdev revisions; usage of
blockdev_propandpool_propis consistent and correct.Also applies to: 78-149
src/dbus/filesystem/filesystem_3_8/mod.rs (1)
32-77: FilesystemR8 D-Bus interface aligns with existing patternsFilesystemR8’s struct, lifecycle helpers, and properties/mutators all delegate via
filesystem_prop/set_filesystem_propand shared props; signal semantics and error types match those used in other filesystem revisions.Also applies to: 80-169
src/dbus/blockdev/blockdev_3_3/mod.rs (1)
34-80: BlockdevR3 registration and property wiring look correctThe struct, constructor, register/unregister, and all properties (including
new_physical_size) correctly reuseblockdev_prop/set_blockdev_propand the shared prop helpers; setter error typing viazbus::Erroris appropriate.Also applies to: 82-171
src/dbus/blockdev/blockdev_3_2/mod.rs (1)
26-72: BlockdevR2 is well-aligned with the R0 baseline and UserInfo semanticsRegister/unregister and all properties look correct and consistent with BlockdevR0; notably,
user_infois explicitly markedemits_changed_signal = "false", which provides a clear baseline for later revisions.Also applies to: 74-145
src/dbus/filesystem/filesystem_3_2/mod.rs (1)
30-76: FilesystemR2 interface is minimal but correctly wiredFilesystemR2’s constructor, lifecycle helpers, and properties correctly reuse
filesystem_prop/pool_propand shared props; signal semantics and types are consistent with later filesystem revisions.Also applies to: 78-122
src/dbus/blockdev/blockdev_3_7/mod.rs (2)
80-169: BlockdevR7 D‑Bus surface and error types look consistent.Property getters cleanly delegate to the shared
blockdev_prop/*_prophelpers usingzbus::fdo::Error, andset_user_infousesResult<(), zbus::Error>as required. Attributes (emits_changed_signalvalues, constant vs mutable props) align with existing blockdev revisions, so this interface wiring looks good.
32-77: Verify that blockdev registration orchestration continues on individual interface failures.
BlockdevR7::registerandunregistercorrectly wrap the zbus object server calls and surfaceStratisResult<()>. However, whether registration continues when one interface fails depends on the callers. Review the higher-level registration code to confirm that it logs individual failures from these methods and proceeds with other blockdevices, rather than stopping on the first error via chained?operators.Similar filesystem registration logic in pool methods intentionally logs warnings and continues processing remaining filesystems when individual registrations fail, allowing the overall operation to succeed even if some interfaces aren't visible on D-Bus. Blockdev registration should follow the same pattern.
src/dbus/blockdev/blockdev_3_5/mod.rs (1)
31-77: Registration wrapper matches other revisions; confirm that call sites handle errors per-interface.
BlockdevR5::registerandunregistercorrectly returnStratisResult<()>, allowing the orchestrator to decide error handling. Please verify that their call sites log registration failures and continue processing remaining devices rather than aborting the entire registration sequence.
| [dependencies.zbus] | ||
| version = "5.12.0" | ||
| optional = true | ||
| git = "https://github.com/mulkieran/zbus.git" | ||
| branch = "sort-introspect-by-interface-name" | ||
| features = ["tokio"] | ||
|
|
||
| [dependencies.zvariant] | ||
| git = "https://github.com/mulkieran/zbus.git" | ||
| branch = "sort-introspect-by-interface-name" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n Cargo.toml | sed -n '230,245p'Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Search for any comments or documentation about the git branch
rg "sort-introspect-by-interface-name" --type toml -B2 -A2Repository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Check if there are any issues or PRs mentioned related to zbus/introspection
rg -i "introspect|zbus.*branch|custom.*git" --type md --type txtRepository: stratis-storage/stratisd
Length of output: 192
🏁 Script executed:
# Look for ADRs or documentation files
fd -e md -e txt | grep -iE "(adr|decision|doc|readme)" | head -20Repository: stratis-storage/stratisd
Length of output: 192
🌐 Web query:
zbus "sort-introspect-by-interface-name" branch
💡 Result:
Do you mean a specific Git branch named "sort-introspect-by-interface-name" in the zbus repo? If so, which remote (dbus2/zbus, dbus2/zbus fork, or your fork) — or would you like me to search public GitHub repos for that branch and return any matches?
🌐 Web query:
zbus 5.12.0 release introspection sorting
💡 Result:
I couldn't find any explicit note about an "introspection sorting" change in the zbus 5.12.0 release notes or changelog. I did confirm zbus 5.12.0 is published (docs.rs/crates and packaging). Would you like me to:
- search the zbus GitHub issues/PRs for introspection/sorting changes (I can dig deeper there), or
- look through the crate source (introspection code) for any sorting-related commits included in 5.12.0?
References: docs.rs listing for zbus 5.12.0 [1], Debian package entry for rust-zbus 5.12.0 [2].
[1] https://docs.rs/crate/zbus/5.12.0
[2] https://launchpad.net/debian/+source/rust-zbus/+changelog
🌐 Web query:
zbus mulkieran fork introspection
💡 Result:
I couldn't find a public "mulkieran" fork of zbus or anything linking that username with "introspection." Do you mean a GitHub user/org (e.g., "mulkieran") or a different spelling? If you want, I can search GitHub and web for that fork and whether it adds/changes zbus introspection — should I proceed (and do you have the exact repo/user name)?
Use released crate versions instead of custom git branches for production code.
The zbus and zvariant dependencies are sourced from a custom git branch (sort-introspect-by-interface-name) instead of stable released versions. zbus 5.12.0 is available as an official release, but the code uses a custom fork instead. This approach:
- Reduces reproducibility and build determinism
- Increases maintenance burden and risk if the branch becomes unavailable
- Complicates dependency auditing and security updates
- Creates divergence from the upstream project without documented justification
Additionally, zvariant is missing an explicit version constraint.
Please address:
- Why is a custom git branch necessary when zbus 5.12.0 is publicly available? If specific functionality is needed, upstream the changes to zbus or document the justification in the repository.
- Specify an explicit version for
zvariant(e.g.,version = "4.x.y").
🤖 Prompt for AI Agents
In Cargo.toml around lines 233 to 242, the zbus and zvariant dependencies point
to a custom git branch which reduces reproducibility and lacks an explicit
zvariant version; replace the git/branch entries with released crate versions
(use version = "5.12.0" for zbus and set an explicit compatible version for
zvariant, e.g., version = "4.x.y"), remove the git and branch keys, and if the
custom branch is truly required either upstream the changes or add a clear
justification and migration plan in the repository docs explaining why the git
branch is necessary and how long it will be maintained.
| counter.fetch_add(1, Ordering::AcqRel), | ||
| ))?; | ||
|
|
||
| manager.write().await.add_filesystem(&path, uuid)?; |
There was a problem hiding this comment.
Manager state update before registrations creates inconsistent state on failure.
Line 56 updates the Manager (adding the filesystem) before attempting any interface registrations. If any subsequent registration fails (e.g., FilesystemR5 on line 103), the function returns an error via ?, leaving the Manager with a filesystem entry that has only partially registered D-Bus interfaces. This creates an inconsistent state where the Manager believes the filesystem is fully registered, but the D-Bus object server has incomplete interface coverage.
In contrast, blockdev/mod.rs updates the Manager after all registrations succeed (line 146), which is safer.
Move the Manager update to occur after all registrations:
let path = ObjectPath::try_from(format!(
"{}/{}",
consts::STRATIS_BASE_PATH,
counter.fetch_add(1, Ordering::AcqRel),
))?;
- manager.write().await.add_filesystem(&path, uuid)?;
-
FilesystemR0::register(
engine.clone(),
connection,
manager,
path.clone(),
pool_uuid,
uuid,
)
.await?;
// ... (remaining registrations)
FilesystemR9::register(
engine.clone(),
connection,
manager,
path.clone(),
pool_uuid,
uuid,
)
.await?;
+
+ manager.write().await.add_filesystem(&path, uuid)?;
Ok(path)Committable suggestion skipped: line range outside the PR's diff.
2 participants
Summary by CodeRabbit
Dependencies
New Features
API Changes
✏️ Tip: You can customize this high-level summary in your review settings.