Skip to content

Sled Agent must manage durable storage for configs, zones, explicitly #2888

@smklein

Description

@smklein

See also: RFD 118

Sled Agent currently configures a few pieces of data outside datasets explicitly allocated in pools:

  • /var/oxide contains a variety of configuration information, including...
    • RSS setup information
    • The "Sled Request" used to launch the sled-agent (including underlay information)
    • A list of "All services which should be launched on this sled"
    • A list of "All services which should be launched on u.2 zpools"
  • /zone contains the "filesystem for all zones"
  • /opt/oxide contains all the "latest installed system images", and is used to update control plane software which exists outside the ramdisk.

Q: So, why is this bad?
A: All those paths are currently backed by a ramdisk -- specifically rpool -- on gimlets.

This means that when we reboot, a significant portion of the necessary configuration information to launch the sled will be lost. Furthermore, for the zonepath filesystems, a significant portion of user RAM will be dedicated to zone-based filesystems, which we'd prefer to distribute to disk-backed file storage.

Here's a list of some of the work we need to accomplish to mitigate this in a production environment:

Metadata

Metadata

Assignees

Labels

Sled AgentRelated to the Per-Sled Configuration and ManagementstorageRelated to storage.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions