You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've marked this as a bug because it is not behaving as expected on first glance, but it's possible that this is actually expected. We will need to discuss this more.
One way that this can be done is by updating the "tracked" replica when any of the non-tracked, preserved replicas are modified. This would require a query (or inspection of in-memory information) to determine the tracked replica and make an update based on whether the modified replica is the tracked replica. In this way, the replica in the higher tier will be marked stale and then the new tracked replica would tier out appropriately.
The following issue was seen with iRODS 4.3.2 and storage tiering 4.3.2.0.
I have a very basic 3-tier group:
tier0_A:unixfilesystem
tier1_A:unixfilesystem
tier2:unixfilesystem
irods::storage_tiering::preserve_replicas
is set totrue
on all 3 tiers. Data is annotated and tiered out as expected.The problem is when one of the preserved replicas is updated:
The access time is not updated:
In order to force a tier-out, you have to trim the other two replicas. Only then does the violating query pick up and start tiering out the changes.
This is similar to #235, but not exactly the same.
The text was updated successfully, but these errors were encountered: