Hi Guido,
thanks for reporting your sculpting experience with us!
When I want to start the VM and the ahci-1.part_blk is not running, the Runtime manager reports with a diagnostic stating vm-nixos needs ahci-1.part_blk. To start my vm, I inspect a different partition on that disk. That starts the part_blk and Runtime starts my VM.
So far so good. The problems start here:
Just a word of caution: So far, most regular Sculpt users - myself included - use merely a single Sculpt file system for storage. Sculpt's mechanisms for inspecting and managing storage devices are there to select and use this single storage place. Your use case - assigning partitions or secondary block devices to components - goes beyond that established path. It is certainly possible - and I know of a few brave Sculpt users who are doing just that - but one needs to be extra careful.
This diagnostic message "vm-nixos requires ahci-1.part_blk" appears because your launcher for 'vm-nixos' has a route to child named "ahci-1.part_blk".
From your description, I gather that you are using two disks. Let's call
them primary and secondary where the primary disk is the one that hosts the Genode partition. In order to access the Genode partition's file system, the Sculpt manager automatically spawns the part_blk and file-system components for the primary disk and the Genode partition and keeps them around as long as the Genode partition is "used".
For the secondary disk, the Sculpt manager needs these components only for the discovery, the inspection, or to perform disk operations. But if none those operations are performed, there is no part_blk or file-system component running.
So far, you relied on Sculpt's automatism to access a partition on the secondary disk. By inspecting another partition of the disk, you forced the Sculpt manager to preserve the part_blk for the secondary disk. This is of course not a robust solution. You should instead add a custom instance of part_blk to your deploy config, which unconditionally stays there. Let's better name it differently than "ahci-1.part_blk", e.g., "manual_ahci-1.part_blk". You can route the block session of this instance to <parent label="ahci-1"/> to let it access the device directly. Once your custom part_blk instance is running, you can route the vm-nixos' block session to "manual_ahci-1.part_blk".
With this approach, you won't need to rely on any side effect of the Sculpt manager's built-in policy. Note however, that the inspection or management of the secondary disk is not expected to work as long as "manual_ahci-1.part_blk" is deployed. The AHCI-1 disk can be used by only one component at a time.
- When the VM runs (and has a session to the part_blk for that
partition, I can format that partition from the Storage component. I get data corruption errors in ZFS on that disk. (But ZFS lives on and repairs it from the other mirror).
That seems to be in violation of The Book para 4.5.8: """The part-block component requests a single block session, parses a partition table, and hands out each partition as a separate block session to its clients. There can be one client for each partition. """
I would expect that the formatter would get an error because it should not get a session to that partition.
Admittedly, I haven't tried handing out one partition of part_blk to multiple clients at the same time. I agree that part_blk should better outright deny this situation because it can only result from unintended routing rules.
I hope that I could shed some light on the mysteries you observed.
Cheers and happy sculpting!
Norman