Welcome to the SNIA Swordfish Mockup site.
You can use this site to test drive a set of static, example Swordfish systems and learn how Swordfish is constructed. The Swordfish mockups are not designed to be interactive systems; they provide an overview of the Swordfish model and static examples of possible configurations.
The Swordfish mockups show the types of information that can be modeled by storage systems in different configurations. They show information that may be returned by those configurations but do not represent actual implementations.
From Swordfish v1.2.0 forward, storage systems can be found directly from the Service Root in the Storage collection (/redfish/v1/Storage). If a system implements the value-add StorageServices feature, a StorageServices collection is also available at the Service Root.
Mockups conform to Swordfish v1.2.9
This working draft adds optical transceiver reporting, configuration, and telemetry. It includes enhanced transceiver mapping to DMTF Redfish and Swordfish physical components, logical components, and relationships, plus the Transceiver and TransceiverMetrics schemas.
This mockup shows an example of a rack-scale DNA Data Storage system, modeling physical components in Chassis as well as logical entities represented as object storage.
The following list provides an index to the available mockups. Select a mockup to open its JSON navigator.
This mockup shows an example of a midrange, iSCSI, external storage system. It shows a small number of instantiated volumes and storage pools, demonstrates the use of storage groups for mapping and masking, and shows the system directly instantiated in the Storage Collection at the Service Root.
This mockup shows an example of a midrange, iSCSI, external storage system with replication. In addition to the configuration shown in the Midrange External Mockup, it adds replication in the form of snapshots and demonstrates the use of consistency groups and storage groups related to replica sets.
This mockup shows an example of a small direct attach configuration, where the storage is attached to a computer system, such as a RAID controller plugged into a server. It shows a small number of instantiated volumes and storage pools, demonstrating a minimal Swordfish configuration.
This mockup shows an example of a filesystem that exposes its underlying capacity source (backend array).
This mockup shows an example of a file system, abstracted away from exposing the backend storage (only the filesystem and fileshare elements are modeled).
This mockup shows an example of a small direct attach configuration where the telemetry service is enabled, including instrumentation of the Swordfish Capacity Metrics templates.
This mockup contains several systems with different configurations under the StorageServices collection. It demonstrates class of service implemented through underlying lines of service, local replication, enterprise block storage with customized class-of-service controls, a server-attached configuration, and a file service implemented on top of block storage.
This mockup demonstrates how implementation capabilities can be advertised, including examples of NVMe namespace creation options.
This mockup follows the Swordfish Integrated Configuration model. The NVM drive is modeled as a PCI-attached drive connected to a system and can also be found through the Storage collection.
This mockup shares many similarities with the simpler device model but adds NVMe Endurance Groups and NVM Sets using the Swordfish StoragePool schema with additional NVMe-specific properties.
This mockup represents a JBOF (just a bunch of flash) enclosure and its contained drives. It reflects a PCIe front-end attach configuration with a set of drives.
This mockup reflects an IP-attached drive configuration with a single Ethernet port configured. It includes a drive configured with a default endurance group and NVM Set, instantiated in the Storage Collection off the Service Root. The network configuration is modeled in the Chassis.
This mockup represents an EBOF (Ethernet-attached bunch of flash) enclosure and its contained drives. It reflects an Ethernet front-end attach configuration with a set of Ethernet-attached drives inside the chassis.
The fabric attach array mockup shows a representation where the array exposes native NVMe resources for both front-end and internal components.
The opaque array reflects a system with an NVMe front end whose internal implementation is vendor specific and not necessarily presented by the vendor. This mockup presents an NVMe front end while also exposing a SATA drive backend, supporting both FRU management and volume or namespace creation.
The NVMe/TCP array mockup shows a representation where the array exposes NVMe/TCP resources for the front-end interface.
This mockup shows a logical exported NVMe-oF subsystem connecting via Ethernet using the Redfish Fabric model. The fabric model uses the Connection schema to characterize allowed host information and Endpoints and Zones to show network connectivity from the device's perspective. It also includes NVMe Domains containing NVM controllers, endurance groups, NVM sets, or namespaces.
This mockup shows a logical exported NVMe-oF subsystem with connectivity via RDMA. Connectivity and access rights are represented using the Redfish Fabric model. The fabric model uses the Connection schema to characterize allowed host information and Endpoints and Zones to show network connectivity from the device's perspective. It also includes NVMe Domains containing NVM controllers, endurance groups, NVM sets, or namespaces.
This mockup presents multiple NVM subsystems. One subsystem contains a discovery controller with discovery information about the others. The other subsystems provide pointers to the subsystem containing the discovery controller.
This mockup shows NVMe SMART Metrics on the NVMe I/O Controller. The NVMe SMART Metrics object mirrors the NVMe SMART log page and can be collected and populated with a single log-page call on the device.
This mockup features NVMe Domains (/redfish/v1/NVMeDomains). NVMe Domains contain a collection of domain members, which can be NVM controllers, endurance groups, NVM sets, or namespaces. Domains can constrain the set of firmware images available to like members. Other domain-level properties include ALUA group definitions, indicating common access characteristics and path prioritization behaviors across namespaces. It also includes examples that report persistent reservations.