<?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: Thick or Thin Provisioning for high I/O Apps in Data Protection</title>
    <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15736#M6475</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The performance impact is minimal. According to the Netapp TR-3965, a performance test performed for MS Exchange on thin and thick volumes, the performance degradation was only 3% on thin volume.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 02 Nov 2012 18:35:18 GMT</pubDate>
    <dc:creator>kkaushal2</dc:creator>
    <dc:date>2012-11-02T18:35:18Z</dc:date>
    <item>
      <title>Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15708#M6469</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello NetApp Community,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there a performance gain by thick provisioning volumes for high I/O applications such as MSSQL and Oracle. I am doing some research and found the following recommendation from an engineer I was speaking with:&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: black; font-family: &amp;amp;quot;Tahoma&amp;amp;quot;,&amp;amp;quot;sans-serif&amp;amp;quot;; font-size: 10pt; mso-fareast-font-family: &amp;amp;quot;Times New Roman&amp;amp;quot;; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"&gt;"As far as the thick provisioning recommendation.&amp;nbsp; It is really being proactive and preventing any DB write delays.&amp;nbsp; By design "thin-provisioning" always takes a small hit when writing (inflating) the volume, this is just to avoid that hit.&amp;nbsp; It is always one of those nice to haves where high I/O apps SQL, Oracle, etc... come into play.&amp;nbsp; If it is something that would cost the customer more then we can discuss removing it as an option."&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: black; font-family: &amp;amp;quot;Tahoma&amp;amp;quot;,&amp;amp;quot;sans-serif&amp;amp;quot;; font-size: 10pt; mso-fareast-font-family: &amp;amp;quot;Times New Roman&amp;amp;quot;; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"&gt;In all the NetApp documentation read I have not come across this information and as I understand it writes are first done to NVRAM and then flushed to the disks every 10 seconds or when it is full.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="color: black; font-family: &amp;amp;quot;Tahoma&amp;amp;quot;,&amp;amp;quot;sans-serif&amp;amp;quot;; font-size: 10pt; mso-fareast-font-family: &amp;amp;quot;Times New Roman&amp;amp;quot;; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"&gt;Can anyone let me know the validity of this statement since NetApp preaches thin provisioning?&amp;nbsp; Thanks.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:29:00 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15708#M6469</guid>
      <dc:creator>cgeck0000</dc:creator>
      <dc:date>2025-06-05T06:29:00Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15712#M6470</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It doesn't make any differences in IO perf ,for thin provisioning you should have to keep monitoring the size of the volume \ LUN .&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;saran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Apr 2012 06:15:50 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15712#M6470</guid>
      <dc:creator>saranraj456</dc:creator>
      <dc:date>2012-04-24T06:15:50Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15716#M6471</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;P&gt;Agreed on NetApp. I don't know of any performance issue with thin vs thick in NetApp both the same spindle count/type in the aggr I haven't heard of a sizing difference. Unless something I haven't heard about.&lt;/P&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Apr 2012 06:30:06 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15716#M6471</guid>
      <dc:creator>scottgelb</dc:creator>
      <dc:date>2012-04-24T06:30:06Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15721#M6472</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;SPAN style="font-size: 10pt; font-family: 'Arial','sans-serif';"&gt;I do not think there is performance gain using thin provisioning, but I can understand in case of your databases like SQL, Oracle; you do not want to be in situation where this is high I/O load and lots of transactions going on and you run out of space on your volume or LUN, which would be un-acceptable. I guess that’s would be NetApp engineer’s opinion when he said it’s nice to have.&amp;nbsp;&amp;nbsp; &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 10pt; font-family: 'Arial','sans-serif';"&gt; &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;Thanks,&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;Sahil&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Apr 2012 10:08:02 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15721#M6472</guid>
      <dc:creator>sahil_anand</dc:creator>
      <dc:date>2012-04-24T10:08:02Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15726#M6473</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi there,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;if thick or thin provisioned, its just a matter of the netapp internal space calculation. NetApp will not create, edit or delete any blocks or metadata when going from thick to thin or vice versa, its just a matter of "accounting" so to say.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The next thing is about space reservation and overwrite reservation, you must have an active monitoring system to make sure your volumes and aggregates do not run out of space.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Last thing, and that is something to consider, is about volume autogrow. If the volumes is configured using autogrow, each time autogrow increases the volume it will give a very slight performance hit due to the internal process of resizing and allocating new blocks. But this impact only hits as long as the resize is running. So you better go with thin provisioning and a fixed size, no autogrow.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Same for snap autodelete, deleting a snap causes a certain performance impact as well, but usualy, like autogrow, its not realy worth to notice.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards,&lt;/P&gt;&lt;P&gt;Thomas&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Apr 2012 13:49:29 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15726#M6473</guid>
      <dc:creator>thomas_glodde</dc:creator>
      <dc:date>2012-04-24T13:49:29Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15731#M6474</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks everyone, I needed a sanity check with this.&amp;nbsp; Like I said it wasn't something I came across.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Apr 2012 14:03:59 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15731#M6474</guid>
      <dc:creator>cgeck0000</dc:creator>
      <dc:date>2012-04-24T14:03:59Z</dc:date>
    </item>
    <item>
      <title>Re: Thick or Thin Provisioning for high I/O Apps</title>
      <link>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15736#M6475</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The performance impact is minimal. According to the Netapp TR-3965, a performance test performed for MS Exchange on thin and thick volumes, the performance degradation was only 3% on thin volume.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 02 Nov 2012 18:35:18 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/Thick-or-Thin-Provisioning-for-high-I-O-Apps/m-p/15736#M6475</guid>
      <dc:creator>kkaushal2</dc:creator>
      <dc:date>2012-11-02T18:35:18Z</dc:date>
    </item>
  </channel>
</rss>

