--- title: "Shared Storage: Which Hosts May Write Under the Reservation?" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/nvme-reservation-type-shared-volume-writer-access" last-updated: "2026-10-21" --- # Shared Storage: Which Hosts May Write Under the Reservation? Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. An attached host's right to write depends on the reservation type and its reservation role. For a single-writer requirement, identify every permitted writer; an attachment list or registered-key count leaves that question unanswered. ## Read four different facts about the shared volume For a shared AI dataset or checkpoint volume, a proposal may identify connected hosts while leaving its writer policy unstated. Read it at four levels. Shared attachment identifies the hosts connected to the volume. Registration associates a host with that volume through a reservation key. The holder has acquired the reservation. The reservation type determines the access restrictions. AWS's NVMe reservations documentation distinguishes registering a key from acquiring a reservation and reporting its status. A registered key therefore needs to be read alongside the reservation state. For the two types compared here, even a single holder leaves the permitted-writer question open. The comparison uses NVM Express Base Specification 2.0d, dated January 11, 2024. The offered controller and namespace must support the reservations and types being discussed. A generic NVMe label does not establish that support. References: [NR1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0d-2024.01.11-Ratified.pdf), [NR2](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) ## NR-48: keep the same three hosts attached Consider fictional case NR-48. Hosts A, B and C are all attached to the same shared namespace. A and B have registered reservation keys; C has not. A holds the reservation. Stipulate controller and namespace support for both illustrated types, supported ordinary user-data Read and Write commands, and all other access conditions satisfied. Compare two hypothetical reservation states. Keep the three attachments, the one namespace, the A/B registrations and holder A unchanged; vary only the reservation type. These are explanatory assumptions, with no real device observations or transition sequence. ## The type changes B's write permission Under Write Exclusive, A's ordinary reads and writes are allowed by the reservation. B and C can read, but their writes encounter Reservation Conflict. Under Write Exclusive – Registrants Only, A and B can read and write. C can still read; its writes encounter Reservation Conflict. B remains a registrant without becoming the holder. These outcomes follow Figure 474. Figure 475 separately classifies command behavior, so the comparison cannot become a rule for every command. It concerns ordinary user-data Read and Write, rather than all administrative, reservation or other operations. References: [NR1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0d-2024.01.11-Ratified.pdf) ## Compare the allowed-writer set with the requirement Suppose NR-48's buyer requires that only A be permitted to write to this namespace while all three hosts remain attached. The first state supplies that reservation-level exclusion for B and C. The second leaves B as another permitted writer, so it fails this stipulated requirement. B does not have to be writing at the moment of review for the difference to matter. A statement that only A is currently issuing writes describes activity; the requirement asks which hosts are permitted to issue them. Likewise, C's blocked write says nothing about B's permission: both are non-holders, but only B is registered. Three attachments, two registered hosts and one holder produce the same counts in both snapshots. None of those counts distinguishes the different writer sets. The useful comparison retains each host's relationship to the identified namespace and the reservation type in force. References: [NR1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0d-2024.01.11-Ratified.pdf) ## Ask for evidence of the offered state For an offered system, ask the appointed storage provider to connect the namespace identity and applicable support to its reported reservation type, holder and registrants at the relevant time. Then ask which identified hosts the reservation permits to write. A capability statement establishes what a system supports; a state report addresses the reservation and registrations present. Both are useful when they concern the offered system. If the supplied evidence only lists attached hosts or registered keys, writer exclusion remains unestablished. A useful response identifies the missing reservation state and maps it to the required writer set. If the requirement also concerns events after a holder fails or the state changes, the two snapshots leave that scenario unanswered. The responsible provider needs separate evidence for the promised behavior. References: [NR2](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) ## Keep the AWS illustration within supported io2 and Nitro scope Amazon EBS provides a concrete shared-block-storage example. Its Multi-Attach guide describes multiple instances sharing a volume in one Availability Zone. Here the provider illustration is limited to supported io2 Multi-Attach volumes on Nitro-based instances with the required operating-system and driver support. The reservations guide describes registration, acquisition and reservation reporting, and lists both compared types. Availability of those features does not establish the state of an offered volume. The supplier needs to identify that state alongside the Multi-Attach capability. AWS also assigns write ordering to applications. Storage-level permission or rejection cannot establish application write ordering, file integrity, completed failover or performance. Those promised outcomes need evidence from the responsible storage and application owners. References: [NR2](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html), [NR3](https://docs.aws.amazon.com/en_en/ebs/latest/userguide/ebs-volumes-multi.html) ## Connect the remaining access and physical-work questions Use the related ANA article when the missing question concerns a controller's access to a namespace. Use the NFSv4.1 restart article when the question concerns recovered client state. Each addresses a different relationship from NR-48's reservation permissions. If the wider project also includes physical storage equipment, Leviathan's rack-and-stack service can discuss separately agreed mounting, IT cabling, labels and installation records. Use the related project inquiry with a nonconfidential equipment list, released rack and connection plans, site constraints and required physical handoff records. Reservation administration and application validation remain with their appointed providers. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [NR1 — NVM Express Base Specification, Revision 2.0d, January 11, 2024](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0d-2024.01.11-Ratified.pdf). Checked 2026-10-20. Section 8.19, Figures 474–475: reservation access and command groups. Named historical edition; offered support needs product-specific evidence. - [NR2 — Amazon EBS: Use NVMe reservations with Multi-Attach enabled volumes](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html). Checked 2026-10-20. Requirements, registration, acquisition, the named reservation types and status reporting. Applied here to supported io2/Nitro arrangements. - [NR3 — Amazon EBS: Attach a volume to multiple instances using Multi-Attach](https://docs.aws.amazon.com/en_en/ebs/latest/userguide/ebs-volumes-multi.html). Checked 2026-10-20. Shared attachment, io2 I/O fencing and application responsibility for write ordering. Capability documentation does not establish an offered volume's reservation state. - [L1 — Leviathan Systems: Rack & Stack / Colocation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Agreed physical mounting, IT cabling, labels and installation records for a separate equipment package. ## Related Leviathan resources - [NVMe ANA: access state by controller and namespace group](/articles/nvme-ana-controller-namespace-access-state) - [NFSv4.1 restart: client state and retained file data](/articles/nfs41-server-restart-state-versus-file-data) - [Storage-network handoff: the physical connections](/articles/gpu-storage-network-physical-handoff) - [Rack-and-stack installation scope](/services/rack-and-stack) - [Discuss a separate physical storage-equipment installation](/contact?service=rack-and-stack&from=%2Farticles%2Fnvme-reservation-type-shared-volume-writer-access) ## Does the wider storage project need physical installation? Share a nonconfidential equipment list, released rack and connection plans, site constraints and required physical records to discuss a separate installation scope and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/nvme-reservation-type-shared-volume-writer-access)