Shared and Mixed-Version Configurations

GIR OSVs can be marked as shared (Shared Object Storage Volume, or SOSV), allowing multiple Hammerspace sites to use the same GIR S3 bucket.

Adding a Shared GIR OSV

Use the --shared flag when adding the OSV:

object-volume-add \
  --node-name <aws-storage-system-name> \
  --logical-volume-name <bucket-name> \
  --storage-class AWS_GLACIER_INSTANT_RETRIEVAL \
  --shared \
  --create-placement-objectives

In the GUI, check the Shared option in the Add Volumes wizard.

Storage Class Validation on Shared OSVs

When a GIR-aware site adds a shared OSV that is already in use by another site, Hammerspace reads the OSV identity file (hs_osv_details) from the bucket root and validates both the recorded storage class and the recorded feature set. Matching storage classes alone is not sufficient.

Storage class. If the recorded class matches the class being requested, the OSV is added. If it does not, the operation fails with:

Cannot add shared Object Storage Volume: storage class mismatch. Bucket configured with <existing_class>, requested <new_class>.

This prevents a GIR bucket from being added as Standard on one site and GIR on another.

Features and feature versions. The identity file also records the features in use on the volume and the version of each. Adding a GIR OSV requires the GIR feature at version 1 or later. A site rejects the volume in either of these cases:

The identity file records a feature this site does not recognize, or records a feature at a version higher than this site supports. This happens when another site is running a newer release. The operation fails with an instruction to upgrade this site before adding the volume.
The requested storage class needs a feature that the other sites sharing the volume do not support. The operation fails, and all sites must remove the OSV and re-add it with the feature enabled.

Mixed-Version Deployments (Sites with and Without Storage Class Support)

GIR is supported beginning with Hammerspace 5.3. All sites sharing a GIR SOSV must run a release that supports GIR.

Do not add or re-add a shared GIR SOSV from a Hammerspace 5.2 site. A 5.2 site does not recognize the GIR storage class recorded in the identity file and can treat the volume as Standard. That bypasses the GIR-aware source-selection and conduit protections, so data placement from the 5.2 site may not respect the GIR cost protections.

A 5.2 site accepts the OSV without error, because it has no awareness of storage class and ignores the newer fields in the identity file. There is no product enforcement preventing this. Between GIR-aware sites, every site must configure the shared OSV with the same storage class, and the feature validation described in Storage Class Validation on Shared OSVs applies.

Legacy OSV Identity Files

Buckets created before storage class support was introduced have no storage class and no feature list in their identity file. A GIR-aware site that reads such a file treats the OSV as Standard class with no features enabled.