Search the docs

Mobility Behavior

Hammerspace’s Data Mobility Engine (DME) treats GIR volumes as a last-resort copy source. DME prefers a usable Standard source whenever one is available. A GIR OSV becomes eligible as a copy source only when no usable Standard source is available; a Standard copy that exists but is not usable does not prevent DME from falling back to GIR.

This behavior is deliberate. Reading from a GIR OSV can incur retrieval and request charges that Standard storage does not incur. Charges vary by AWS region and by usage pattern; consult Amazon S3 pricing for current rates. DME is designed to avoid incurring these charges during routine mobility operations.

Key practical effects:

  • A keep-online objective on a share that has a GIR instance creates a NAS copy from GIR, incurring the retrieval cost once. Later reads use that NAS copy for as long as it remains available and retained. If that NAS copy is later removed or becomes unavailable, another GIR retrieval can be required.

  • Multiple non-GIR copies are always preferred over GIR for COPY and clone operations.

  • For COW (copy-on-write) splits, Hammerspace prefers a Standard archive copy when both Standard and GIR copies exist, and uses GIR when it is the only archive choice. When a file has both NAS and GIR copies, the live side retains the NAS copy while the snapshot side can remain GIR-only.

  • optimize-for-capacity can cause instance drops, including archive and GIR instances, when no objective requires that instance. For example, a GIR instance may be dropped if no place-on objective or other objective depends on it.

  • DME does not create new copies on a GIR volume solely because other volumes are under capacity pressure. However, if a GIR volume is itself over its configured capacity threshold, DME can raise the egress capacity cost and may move files off the GIR volume. Configure the GIR volume with unlimited capacity, or with thresholds that effectively disable capacity pressure, if you do not want capacity-driven evictions from a GIR volume.

How GIR Contributes to Availability and Durability Scoring

GIR OSVs are assigned the same nominal availability and durability values as Standard OSVs. The Hammerspace defaults are 99.99% (four nines) availability, 99.9999999% (nine nines) durability, and a five-minute online delay. These are configurable Hammerspace defaults — they are not fixed limits, and they are not AWS service guarantees. For AWS’s published characteristics of each storage class, see Amazon S3 storage classes.

The rules that determine what you see are:

  • Existing GIR instances contribute to alignment using their configured Hammerspace availability and durability values.

  • The DME does not create a new GIR instance solely to satisfy a generic availability or durability objective.

  • An explicit placement objective can still place data on GIR.

The practical result: if a share has a four-nines availability objective and the only available volume is a GIR OSV, the system does not upload to GIR to satisfy the objective, and the share remains misaligned. To place data on GIR, use an explicit place-on or confine-to objective that targets archive-object-volumes or a specific GIR OSV.