--- title: "Why One Connected NVMe Controller Can Be Preferred for One Namespace and Not Another" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/nvme-ana-controller-namespace-access-state" last-updated: "2026-10-20" --- # Why One Connected NVMe Controller Can Be Preferred for One Namespace and Not Another Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Two connected NVMe controllers can provide different access characteristics to the same namespace, and their preferred roles can reverse for another namespace. Interpret ANA for the identified controller and namespace group before comparing paths. A connection status alone cannot establish equivalent access or the loss of data. ## A connected controller does not settle access to every namespace A storage proposal may show both controllers connected and describe the paths as equivalent. The missing detail is what each controller offers for the particular namespace the host needs. NVM Express's Q1 2020 webcast answers explain why access paths within a storage system can have different performance characteristics. Their shared destination does not make their access characteristics identical. For a buyer reviewing AI storage, three questions therefore need separate answers: which connection exists, which namespace it reaches, and what access that controller provides to that namespace. An equipment or port list addresses the first question. It cannot stand in for the remaining two. References: [E1](https://nvmexpress.org/answering-your-questions-nvme-of-1-1-specification-key-features-and-use-cases-webcast/) ## Read the controller, group and state together NVM Express Base Specification 2.0c, ratified October 4, 2022, defines Asymmetric Namespace Access (ANA) state for a controller-to-ANA-group relationship. Namespaces in a group share that relationship's state and transitions. Both Optimized and Non-Optimized permit supported namespace operations. Non-Optimized may involve lower performance or less effective subsystem-resource use; neither label supplies a speed ratio. Inaccessible means that relationship cannot access the group's user data and may later change. Persistent Loss means persistently inaccessible through that relationship, which cannot transition to another ANA state. Change describes a transition; it need not be visible to the host. ANA reporting is optional. A controller supporting it must support reporting Optimized; support for reporting each of the other four states is optional. This named historical edition explains the mechanism, without establishing an offered system's support. References: [N1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf) ## Two controllers can have opposite preferred relationships Consider one fictional host with connected controllers A and B in the same NVM subsystem. Stipulate that two shared namespaces, N1 and N2, are attached to both controllers. N1 belongs to ANA group G1; N2 belongs to a different group, G2. Assume the illustrated ANA reporting and states are supported. These are explanatory assumptions, not a product configuration or an observed installation. At the first snapshot, A reports Optimized for G1 and Non-Optimized for G2. B reports Non-Optimized for G1 and Optimized for G2. N1 therefore has optimized access through A, while N2 has optimized access through B. Compare A/G1 with B/G1 for N1, and A/G2 with B/G2 for N2. That gives four controller-to-group relationships across the two namespaces, with two illustrated paths for each namespace. A subsystem-wide preferred-controller label would hide this arrangement. The useful comparison preserves A's optimized relationship for N1 and B's optimized relationship for N2. The related dual-port article explains the separate question of access paths and data copies. References: [N1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf) ## Change one relationship without declaring the namespace lost Now take a second fictional snapshot. Change only A/G1 to Inaccessible. Keep B/G1 Non-Optimized, A/G2 Non-Optimized and B/G2 Optimized. Both controllers remain connected by assumption. For N1, the example now contains one inaccessible relationship and one non-optimized access relationship through B. For N2, the two original relationships remain. The changed A/G1 entry does not change A/G2 or establish that B has lost access to N1. Describing B/G1 as already failed would erase the distinction between non-optimized access and inaccessible access. In a separate alternative, set A/G1 to Persistent Loss and keep the other three relationships as stipulated. The loss remains scoped to A/G1; the example still includes non-optimized access to N1 through B. It does not establish that N1's data was destroyed. These snapshots describe reported access characteristics. Neither supplies an observed service result or interruption duration. References: [N1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf) ## Linux 6.18 gives optimized access preference The Linux 6.18 NVMe multipath documentation says namespace paths with the same identifier are integrated into a single block device. For I/O to that device, multipath selects an underlying path. Its stated policies choose an available optimized path over a non-optimized path. When Linux 6.18 native NVMe multipath is in use, applying that rule to the first hypothetical snapshot gives A preference for N1 and B preference for N2. The host's preferred path can therefore depend on the namespace being accessed. Keep the software version with this explanation. Comparing another operating system or release requires its applicable host documentation. References: [K1](https://www.kernel.org/doc/html/v6.18/admin-guide/nvme-multipath.html) ## Ask what the supplied evidence actually demonstrates When comparing offers, ask the storage supplier to identify the offered controllers, relevant firmware and host software, namespace identities, ANA group membership and supported reporting states. Then compare the reported relationships for the namespace that serves the requirement. A missing relationship should remain an unanswered question rather than being filled with an assumed Optimized state. For physical reachability, retain the actual equipment and connection identities. For namespace identity, obtain the supplier's mapping showing whether the paths refer to the same namespace. For delivered access, ask what the supplied system or workload evidence establishes for that namespace, through which controller, under what conditions and when. Keep a proposed arrangement distinguishable from documented support and an observed result. For example, an offer that supplies the first fictional snapshot makes its opposite access preferences assessable. An offer that supplies only two connected-controller entries leaves that distinction unanswered. A throughput or availability claim needs evidence addressing its own requirement. ## Connect a separate physical installation need to its own scope If the selected storage also needs equipment mounting or physical IT connections, Leviathan's rack-and-stack service can discuss that work, its labels and physical handoff records. Use the related service and project-inquiry links with a nonconfidential equipment list, rack positions, released connection schedule and site constraints. Identify the appointed storage and host-software owners alongside that package. ANA interpretation and the evidence for storage service belong with those owners; they are not established by a physical installation record. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [N1 — NVM Express Base Specification, Revision 2.0c, October 4, 2022](https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf). Checked 2026-10-20. Sections 8.1–8.1.3 and informative 8.10 define group relationships, reporting support and state scope in this historical edition. - [K1 — Linux 6.18 documentation: Linux NVMe multipath](https://www.kernel.org/doc/html/v6.18/admin-guide/nvme-multipath.html). Checked 2026-10-20. Introduction and Policies explain namespace-identifier aggregation and optimized-path preference for the Linux NVMe host driver. Used without configuration or tuning instructions. - [E1 — NVM Express: NVMe-oF 1.1 webcast answers, Q1 2020 context](https://nvmexpress.org/answering-your-questions-nvme-of-1-1-specification-key-features-and-use-cases-webcast/). Checked 2026-10-20. Questions 1 and 2 explain why paths to a shared namespace can differ. Historical architectural context; its operating-system support statements are not adopted as current. - [L1 — Leviathan Systems: Rack-and-Stack / Colocation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Current physical mounting, IT-cabling, labels and handoff scope, with a project inquiry. Software commissioning is not a standard installation inclusion. ## Related Leviathan resources - [Dual-port NVMe: access paths and data copies](/articles/dual-port-nvme-ssd-paths-versus-data-replicas) - [NVMe submission and completion queues](/articles/nvme-submission-completion-queues-versus-media-parallelism) - [Storage-network physical handoff](/articles/gpu-storage-network-physical-handoff) - [Rack-and-stack installation scope](/services/rack-and-stack) - [Discuss a separate storage-equipment installation](/contact?service=rack-and-stack&from=%2Farticles%2Fnvme-ana-controller-namespace-access-state) ## Selected storage needs physical installation? Share the equipment list, released rack and connection plans, site constraints and required physical records to discuss installation scope and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/nvme-ana-controller-namespace-access-state)