Troubleshooting

Data is not being placed on the GIR OSV. Check whether the share has an explicit place-on-archive-object-volumes or confine-to-archive-object-volumes objective. Availability and durability objectives alone will not drive data to GIR. Confirm with objective-list that the objective exists and is applied to the correct share.

The GIR OSV is not appearing in the archive-object-volumes Volume Group. Verify that the OSV was actually created with --storage-class AWS_GLACIER_INSTANT_RETRIEVAL. Use object-volume-list and check the Storage class field. If the field shows Standard, the OSV was not added as GIR. Delete the OSV and re-add it with the correct storage class.

"Invalid storage-class" error on the CLI. The value must be one of the enum tokens, STANDARD or AWS_GLACIER_INSTANT_RETRIEVAL. The token is not case-sensitive — for example, AWS_glacier_instant_retrieval is accepted — but the spaced display form 'AWS Glacier Instant Retrieval' is rejected because it is not a valid token.

Storage class parameter rejected on a non-AWS storage node. GIR is supported only on Amazon S3 storage systems. The --storage-class parameter is not valid for Azure, GCP, or Hammerspace S3 nodes.

Storage class mismatch error when adding a shared OSV. Two storage-class-aware sites are attempting to share an OSV with conflicting storage class designations. The second site’s add request does not match the storage class recorded in the OSV identity file (hs_osv_details). Both sites must add the SOSV with the same storage class.

Unexpected AWS billing for data that has already been deleted from the share. This is expected behavior caused by the 90-day AWS minimum retention period. Hammerspace applies a 90-day minimum TTL at the Cloud Mover layer, but AWS billing for recently deleted objects continues through the end of the 90-day window. Use AWS billing tools directly to monitor charges.

Hammerspace-reported capacity on the GIR OSV does not match AWS billing. This is a known limitation. Because of the 90-day minimum billing window, recently deleted data may still be billed by AWS after it no longer appears in Hammerspace capacity reports. These figures cannot be reconciled within the product in this release.

A GIR OSV appears to be used as a replication conduit. This should not occur: GIR OSVs are excluded from the replication transfer conduit pool by default. If you observe replication traffic on a GIR volume, contact Hammerspace Support.

Cannot change the storage class on an existing OSV. By design. Storage class is immutable. Create a new OSV with the desired class and use placement objectives to migrate data.

Setting a lower total capacity on an OSV is rejected. You cannot set the total capacity of an object storage volume, GIR or otherwise, below the amount of data already stored on it. The update is refused with the error The specified total capacity '<value>' must be greater than current used bytes '<used>'. Choose a value above the current used capacity, or move data off the volume first.

New GIR copies are not being created to satisfy an availability objective. By design. Availability and durability objectives alone do not cause Hammerspace to create a new GIR copy. Apply an explicit place-on objective that targets archive-object-volumes or a specific GIR OSV. Existing GIR copies are still considered when Hammerspace evaluates the current data layout.