Search the docs

How Hammerspace Manages GIR

Hammerspace applies a set of default policies to GIR volumes specifically designed to prevent unexpected egress and storage charges. The table below summarizes this behavior; each item is discussed in more detail in later sections.

Area GIR behavior

OSV storage class

Set at creation; immutable for the life of the OSV

Default Volume Group

Automatically added to archive-object-volumes

Placement

Data is placed on a GIR OSV only when an explicit place-on or confine-to objective targets it

Availability/durability objectives

GIR does not receive new copies to satisfy generic availability or durability goals alone

Replication transfer conduit

Excluded by default

Mobility — copy source

Used only as a last resort when no other copy exists

Watermark-based evacuation

Not applied to GIR OSVs

COW split

Neither the base nor the clone is left with only a GIR instance unless unavoidable

Garbage collection

Runs once per day on GIR volumes (less frequent than standard OSVs)

Minimum TTL

90-day minimum TTL applied at the Cloud Mover to match AWS billing

GIR Is a Volume-Level Designation

The GIR storage class applies at the OSV level, not at the share or file level. Every file that Hammerspace places on a GIR OSV is uploaded to AWS with the x-amz-storage-class: GLACIER_IR request header. It is not possible to mix GIR and Standard storage within a single OSV.

Hammerspace only writes data blobs in the Merkle tree (under the Hammerspace_v2/ prefix) as GIR. OSV management files — the identity file (hs_osv_details, in the bucket root), the site reservation file, and I/O test files — are always stored as Standard class. The S3 bucket itself carries no special GIR designation; it is the Hammerspace Cloud Mover that applies the storage class per blob.