Core Concepts: The Shared Object Storage Volume

A GFS is one namespace stretched across multiple Hammerspace clusters, where each cluster is a site. Each site is designed to keep operating on its own if the others are down or unreachable. Sites stay in sync by continuously exchanging metadata — the file system’s structure, names, timestamps, permissions, and custom metadata — not by copying every file everywhere.

Hammerspace replicates instances, not copies. When you copy a file in a traditional system, you create a second, independent file that happens to have the same contents. An instance is the same file, which can physically exist in two or more locations at once; to the file system it is still one file. This is possible because metadata is disaggregated from data and kept consistent across all sites.

Sites exchange file data (as opposed to metadata) through a shared bucket — an object-storage bucket reachable by every participating site. When Hammerspace adds that bucket to a cluster as a shared resource, it becomes a shared Object Storage Volume, usually shortened to shared OSV. The owning site uploads changed data to the shared OSV; a requesting site downloads it from the shared OSV. Metadata never travels through the bucket — only data.

Because data moves through deduplicated, compressed (and optionally encrypted) objects, the bytes transferred between sites are often far smaller than the file itself: only changed chunks move. See The shared Object Storage Volume in depth.

An objective is a rule that tells Hammerspace what to do with files matching some condition — where to place instances, how long to keep them, whether to keep an extra copy nearby, and so on. Objectives are written in plain language (for example, "keep files used in the last 7 days on local storage") and are typically layered: a share commonly has several objectives active at once, each handling a different concern.

Three objectives matter immediately for a global file system, because GFS applies one of them automatically to protect data during cross-site conflicts:

The full mechanics of writing and applying objectives — including how each site manages its own objectives independently of the others — are covered in Objectives and data placement.

At any moment a file is owned by the site that last wrote to it. Ownership matters when another site needs data it does not hold locally: that site contacts the owning site and orchestrates mobility of the data to itself through the shared OSV. Ownership also governs what happens when two sites change the same file at the same time (How Conflicts Are Handled).