SVM Root Volumes and Storage GRID

[sanadmin_do]

We have been using a Storage GRID since the middle of last week. We have now relocated the first volumes. Since we will also have to move the SVM root volumes in the future, the question arises as to whether we should specify the same parameters for the move as for the "normal" data volumes. We set the tiering policy to "auto" when migrating the data volumes. Set the "tiering-minimum-cooling-days" parameter to "8". The SVM root volumes should not have much cold data. Does it make sense to leave the root volumes completely on the SSD's? They are only 1 GB in size.

[Ontapforrum]

svm root volume hardly contains any concerning space, so leave it alone. The primary purpose of StorageGRID (FabricPool) is to reduce storage footprints and costs associated with Active "user--data" on the high-performance/SSD local tiers. If a catastrophic disaster destroys the local tier, a new environment cannot be created using the data on the cloud tier b'cos Access control lists (ACLs), directory structures, and metadata (WAFL) always stay on the local tier. This is not a Data Protection or DR feature, for data protection/DR, you will need to setup snapmirror/vault.

Also, I see you have mentioned the word 'migrating' , I guess you meant "tiering" inactive data to StorageGRID.

[EWILTS_SAS]

Tiering won't work on an SVM root volume.  The volumes must have a space guarantee of none for tiering to be enabled.  svm root volumes have space-guarantee = volume.

"Error: command failed: Volumes that support tiering must have a space guarantee of "none"."