Skip to content

Storage

The storage subsystem presents logical tiers and pools over provider storage, with race-safe reservations and capability-based placement. The customer speaks Disk / Volume / Tier; the provider layer translates.

Storage

Tiers

Storage tiers are commercial classes (for example Standard SSD, NVMe, High IOPS, Archive) with priority, root/volume allowances and default IO limits. They are never inferred from provider names.

Pools

A storage pool is the logical aggregate: location, tier, capability flags (supports_vm_disks/images/iso/snapshots/clones), health (online|degraded|offline|read_only|full|unknown), overcommit ratio, maintenance mode and soft deletes.

Provider mappings

Provider identity lives only in provider mappings (connection + node + storage id + type + content + capabilities). Mappings are written by the storage mapping sync (idempotent, scheduled every 15 minutes).

Reservations

Reservations are transaction-safe holds: the reserve operation takes the pool row lock and moves reserved_bytes in one critical section. Reserved rows move to committed, released or expired; a sweep releases expired rows whose task is dead.

Placement

Placement filters (enabled/schedulable/health/maintenance, location + provider accessibility, capability superset, tier, free capacity with overcommit) and scores candidates (free %, tier priority, health, image locality).

Capacity math: schedulable = capacity × overcommit − provider_used − reserved. Thin provisioning keeps logical allocations separate from physical usage.

Health

php artisan pterocloud:storage:health
php artisan pterocloud:storage:inspect <pool_uuid>
php artisan pterocloud:storage:audit

Warnings are reported at 70/80/90/95 % thresholds. Unhealthy pools are unschedulable; mappings are never auto-deleted.