News Stay informed about the latest enterprise technology news and product updates.

User response about NetApp and FC LUN snapshots - UPDATED

Last week, I blogged about discussions I’ve recently had with NetApp and NetApp customers about the company’s messaging and products. One of the focal points of the debate was what users understood about best practices for overhead on FC LUN snapshots. A couple of users I’d talked to prior to reporting on NetApp’s analyst day event said NetApp best practices dictate at least 100% overhead on FC LUNs, but that NetApp salespeople tell them a different story before the sale.

However, when I followed up with NetApp, officials told me in no uncertain terms that their most current best practices for FC LUNs dictate the same snapshot overhead as any other type of data: 20%.

After posting on this, I got another response from a NetApp customer disputing those statements that seems worthy of adding to the discussion. Here’s the message verbatim:

Netapp is being a little disingenuous. The overhead for SNAP shots is recommended to start at 20% but for LUNs Netapp’s best practices recommends an additional 100% (Fractional Reserve) be available for overwrites after the snapshot is taken.

So 100GB LUN needs 20% for snap (changed data) + 100% for overwrites. If Fractional Reserve is set at 100% (according to Netapp best practices) the first snapshot of a 100GB LUN will reserve 100GB of free space in the volume for future overwrites. This space is reserved until all the snapshots are deleted. Note that Netapp LUNs are files that reside on volumes with a growth/size limit and not partitions like traditional storage arrays from HDS or EMC.

Here is what Netapp says in their Thin Provisioning White Paper. For LUNs used by applications like Databases Netapp recommends that the Fractional Reserve be set at 100%.  A lot of the Netapp sales people don’t understand how it work or avoid the subject.


Fractional reserve is a volume option available in Data ONTAP 6.5 and later that determines how much space Data ONTAP will reserve for Snapshot overwrite data for LUNs and space-reserved files. The default value is 100%. Data ONTAP removes or reserves this space from the volume as soon as the first Snapshot copy is created. For example, as shown in Figure 4 on the left-hand side, a 100GB volume is shown with two 20GB LUNs. Assuming the LUNs are full and a Snapshot copy is created, Data ONTAP by default will reserve 40GB (2 x 20GB) of space in the volume to assure that there is always enough space for both the LUNs and all the Snapshot data, even if the LUNs are completely overwritten. This is depicted in the middle of Figure 4. As depicted on the right-hand side, if fractional_reserve is set to 60% when the Snapshot is created, instead of reserving 40GB in the volume, Data ONTAP will reserve only 24GB (60% * [2 x 20GB])

NetApp has not yet responded to my requests for comment .

NetApp has responded with the following comment:

The best practice for Snapshot overhead (for LUNs) has been changed based on the availability of a feature called Snapshot autodelete. This feature, available since the introduction of Data ONTAP 7.1, is a volume setting that allows policy based deletion of Snapshot copies. With autodelete turned on, there is no longer a requirement for 100% overhead. Actual Snapshot overhead requirements should be based on the data change rate, the number of snapshots taken and the duration of time that the Snapshots are required. Based on these parameters, the actual Snapshot overhead will vary. Since Data ONTAP writes changes in 4KB increments, Snapshot space utilization is very efficient.

Peanut gallery, feel free to weigh in.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Auto delete, deletes existing snapshots and it has nothing to do with the 100% fractional reserve settings recommended by Netapp for LUNs does it? The next time you take a snapshot of a LUN you reserve 100% over write space again. You also have been forced to delete a snapshot that you may have wanted to keep. What has really changed? So next up we should hear Netapp talking about setting the factional reserve to less than 100% and using volume auto grow combined with snapshot auto delete. If you bite on this one be sure you test how well it really works before you bet your mission critical application on it. Remember how Netapp always talks about how easy snapshots are to manage? Notice when they were first asked about snapshot overhead Netapp never mentioned auto delete, auto grow, and fractional reserve? Try configuring and managing this mess for 60+ LUNs and you will start to get the picture why. I am not a Netapp hater, I support a lot of their stuff. I just think they need to stop misleading people about snapshots and LUNs.
Hi Beth, Just circling back on this topic now that I've finally had a chance to focus on it again. I've been blogging on it over the past couple of days here: NonSense - sorry to hear about your struggles realizing the benefits of our products in your environment. I recommend studying the Provisioning Manager (and/or SnapDrive) solutions discussed here: Val Bercovici Office of the CTO NetApp