Appendix A — Glossary · Qumulo Field Guide

Definitions here are written to be said out loud, not recited. Where a term has a precise mechanism behind it, the entry points at the module that explains it.

Terms marked [vendor] are Qumulo product or marketing names rather than industry-standard terminology — worth knowing, but do not assume a customer shares the vocabulary.

Architecture

Shared-nothing: A cluster design in which nodes do not share memory or disks. Each node owns its own resources and coordinates with the others over the network. The practical consequence is that there is no single component whose failure or capacity ceiling becomes the cluster’s. See Module 3.
Single namespace: One filesystem tree spanning the entire cluster, reachable from any node. The customer-facing version: “you do not have to know where the data is, and you do not have to carve the estate into islands.”
Scalable Block Store (SBS): [vendor] The layer beneath Qumulo’s file system that maps files onto protected storage. It presents the file system with an address space where protection has already been applied. This is the reason the same file system can run on physical media and on cloud object storage without being rewritten. See Module 3.
Protected virtual address space: A virtual block address range in which protection is already applied, so layers above it can treat storage as reliable. Qumulo organises this into 4K blocks holding either data or erasure-coding hashes.
Erasure coding: Parity-based data protection that survives failures without storing whole additional copies. More space-efficient than mirroring. In Qumulo the ratio of data to coding blocks adjusts as nodes are added, so protection efficiency improves with cluster size. Never quote a specific usable-capacity percentage from memory — pull it from current documentation.
Bit rot: Silent data corruption that accumulates on media over time without being reported as an error. Matters most for data that sits untouched for years — archive, surveillance retention, genomics.
Global Transaction System: [vendor] The mechanism that makes multi-block writes atomic across nodes: all the relevant blocks are written, or none are.
Immediate consistency: Also called strong consistency. A write is not acknowledged until it is durable, so any subsequent read returns it. Distinct from eventual consistency, where readers may briefly disagree. It has a real write-latency cost, and saying so is what makes you credible when you claim the benefit. See Module 3.
Real-time metadata aggregation: Maintaining directory-level totals continuously as files change, propagating them up to the root, so a capacity or activity query is a lookup rather than a tree walk. This is the mechanism behind Qumulo’s instant analytics and, arguably, the reason the product exists.
Tree walk: Traversing every directory and file to compute totals. The conventional way to answer “how much space is this using.” On a filesystem with billions of files it is slow enough that most organisations run it nightly, weekly, or never — which is why their capacity data is always stale.
Failure domain: The scope of what is lost when one thing fails — a disk, a node, a rack, a site. Protection schemes are designed around which domains must survive. The question worth asking a customer is which of these they have actually tested.

Products

Qumulo Core: [vendor] The file system software itself, across all deployment models. Qumulo’s tagline for it is “distributed data operating system.”
Cloud Native Qumulo (CNQ): [vendor] Self-managed deployment on AWS, Azure, and GCP. Self-managed is the operative word — the customer’s team operates it.
Azure Native Qumulo (ANQ): [vendor] A Qumulo-managed service on Azure. The managed versus self-managed distinction is the primary decision axis against CNQ on Azure, and it is fundamentally a question about who owns operations, not about features.
Qumulo Stratus: [vendor] Positioned by Qumulo as a “data platform for zero-trust, AI-native environments.”
Qumulo Nexus: [vendor] Positioned as an “AI-assisted management portal.” Public technical documentation is access-restricted, so treat detailed public capability descriptions with caution and attribute them.
NeuralCache: [vendor] Qumulo’s “AI-enabled predictive caching and prefetch engine.”
NeuralProtect: [vendor] Qumulo’s “real-time ransomware and malware protection.”
NeuralSearch: [vendor] Qumulo’s “storage-native search for unstructured data at scale.” Note the naming collision risk: WEKA’s platform is called NeuralMesh. Be the person who disambiguates these clearly. See Module 12.
Cloud Data Fabric: [vendor] Qumulo’s “advanced file system for any data, anywhere.”
Qumulo Accelerators: [vendor] “Lightweight data engines for remote and constrained environments.”
qq: Qumulo’s command-line tool. Architecturally important detail: it is a wrapper over the REST API, not a separate control path. Anything qq does, the API can do — which is the foundation of any automation conversation.

Access and identity

SMB: The Windows-native file protocol. In practice this means Active Directory identity, Windows ACLs, and client behaviour that differs meaningfully from NFS.
NFS: The UNIX/Linux file protocol. NFSv3 is stateless and still extremely common; NFSv4.1 adds state, stronger security, and different locking semantics. Which version a customer runs changes the design.
Multiprotocol access: Serving the same data over more than one protocol. The hard part is never the protocols; it is the permission model, because POSIX modes and Windows ACLs do not express the same things. Ask early and specifically.
POSIX: The UNIX permission and filesystem-semantics standard. Its permission model (owner/group/other) is less expressive than Windows ACLs, which is precisely why multiprotocol permission collisions happen.
GPUDirect Storage: An NVIDIA data path allowing storage to move data directly into GPU memory, bypassing a bounce through host memory. Frequently a hard requirement in GPU training evaluations. If a customer requires it, establish that early — it narrows the field fast.

Commercial and field

Architectural ceiling: What a design permits, as opposed to what a vendor will support. Useful for exactly one thing: assuring a customer that growth will not force a re-platform. It is not a deployment recommendation, and presenting it as one is how an SA ends up owning an unsupportable configuration.
Supported configuration: What the vendor will actually stand behind. This is the number that governs what you may propose. Always smaller than the architectural ceiling, and versioned.
Compelling event: The thing that makes a customer act on a timeline: end of support, a failed audit, a capacity wall, a facility move, a project with a date. In the absence of one, the most likely outcome is that nothing happens. Qualify for this early.
Vendor claim: An assertion published by a vendor that has not been independently verified. Not a synonym for “false” — it is a statement about provenance. The professional habit is to attribute it (“Qumulo publishes a figure of…”) rather than restate it as measured fact. Every claim on this site is labelled this way; see Appendix N.
Proof of concept (POC): A time-boxed technical validation with defined success criteria and a written exit plan. Without those two things it is not a POC — it is unpaid consulting that ends when someone gets tired. See Module 12.
Total cost of ownership (TCO): The full cost of a platform over its life: hardware or cloud compute, capacity, support, migration, data transfer, networking, facilities, operational staff time, and risk. The categories customers most often omit are migration effort and staff time, and they are frequently the largest.