<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SVM Root Volumes and Storage GRID in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445552#M42515</link>
    <description>&lt;P&gt;svm root volume hardly contains any concerning space, so leave it alone. The primary purpose of StorageGRID (FabricPool) is to &lt;STRONG&gt;reduce storage footprints&lt;/STRONG&gt; and costs associated with Active "&lt;STRONG&gt;user--data&lt;/STRONG&gt;" on the high-performance/&lt;STRONG&gt;SSD&lt;/STRONG&gt; local tiers. If a catastrophic disaster destroys the local tier, a new environment&lt;STRONG&gt; cannot&lt;/STRONG&gt; &lt;STRONG&gt;be created using the data on the cloud tier&lt;/STRONG&gt; 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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, I see you have mentioned the word 'migrating' , I guess you meant "&lt;STRONG&gt;tiering&lt;/STRONG&gt;" inactive data to StorageGRID.&lt;/P&gt;</description>
    <pubDate>Mon, 26 Jun 2023 10:49:05 GMT</pubDate>
    <dc:creator>Ontapforrum</dc:creator>
    <dc:date>2023-06-26T10:49:05Z</dc:date>
    <item>
      <title>SVM Root Volumes and Storage GRID</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445550#M42514</link>
      <description>&lt;DIV class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;We have been using a Storage GRID since the middle of last week.&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;We have now relocated the first volumes.&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;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.&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;We set the tiering policy to "auto" when migrating the data volumes.&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;Set the "tiering-minimum-cooling-days" parameter to "8".&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;The SVM root volumes should not have much cold data.&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;Does it make sense to leave the root volumes completely on the SSD's?&lt;/SPAN&gt;&lt;/SPAN&gt; &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;They are only 1 GB in size.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&amp;nbsp;&lt;/DIV&gt;</description>
      <pubDate>Wed, 04 Jun 2025 09:47:36 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445550#M42514</guid>
      <dc:creator>sanadmin_do</dc:creator>
      <dc:date>2025-06-04T09:47:36Z</dc:date>
    </item>
    <item>
      <title>Re: SVM Root Volumes and Storage GRID</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445552#M42515</link>
      <description>&lt;P&gt;svm root volume hardly contains any concerning space, so leave it alone. The primary purpose of StorageGRID (FabricPool) is to &lt;STRONG&gt;reduce storage footprints&lt;/STRONG&gt; and costs associated with Active "&lt;STRONG&gt;user--data&lt;/STRONG&gt;" on the high-performance/&lt;STRONG&gt;SSD&lt;/STRONG&gt; local tiers. If a catastrophic disaster destroys the local tier, a new environment&lt;STRONG&gt; cannot&lt;/STRONG&gt; &lt;STRONG&gt;be created using the data on the cloud tier&lt;/STRONG&gt; 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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, I see you have mentioned the word 'migrating' , I guess you meant "&lt;STRONG&gt;tiering&lt;/STRONG&gt;" inactive data to StorageGRID.&lt;/P&gt;</description>
      <pubDate>Mon, 26 Jun 2023 10:49:05 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445552#M42515</guid>
      <dc:creator>Ontapforrum</dc:creator>
      <dc:date>2023-06-26T10:49:05Z</dc:date>
    </item>
    <item>
      <title>Re: SVM Root Volumes and Storage GRID</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445653#M42528</link>
      <description>&lt;P&gt;Tiering won't work on an SVM root volume.&amp;nbsp; The volumes must have a space guarantee of none for tiering to be enabled.&amp;nbsp; svm root volumes have space-guarantee = volume.&lt;/P&gt;&lt;P&gt;"Error: command failed: Volumes that support tiering must have a space guarantee of "none"."&lt;/P&gt;</description>
      <pubDate>Tue, 27 Jun 2023 21:02:14 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/SVM-Root-Volumes-and-Storage-GRID/m-p/445653#M42528</guid>
      <dc:creator>EWILTS_SAS</dc:creator>
      <dc:date>2023-06-27T21:02:14Z</dc:date>
    </item>
  </channel>
</rss>

