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 |
Placement |
Data is placed on a GIR OSV only when an explicit |
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.
|