Skip to main content
NetApp Knowledge Base

What are the space requirements for LUNs with volumes that have 100% fractional reserve?

Last Updated:


Applies to

  • ONTAP 9
  • Data ONTAP 7 and earlier
  • SAN
  • FlexPod
  • File Reservation
  • Fractional Reserve (fractional_reserve)


  • Fractional reserve is enabled by default for Space-reserved files or LUNs with thick volume provisioning for taking snapshots and overwrites. See recommended volume and file or LUN configuration
  • Logical space equal to twice the size of the Space-reserved files or LUNs will be consumed after the first snapshot. The reserved space size can be confirmed under reserved item via df -r command
  • The space required for a LUN containing volume with 100% fractional reserve follows the 2x LUN + delta rule
  • The 2x LUN + delta rule specifies the requirement (for volumes with fractional_reserve at 100) for the LUN containing volume to have up to an extra 100 percent of the space available to the mapped host that the host would expect to see available for writes on that LUN, + room for the snapshot rate of change.
  • The typical windows host would expect to be able to write to almost 100% of its available LUN at all times if the LUN is used in active production as opposed to archive.


  • On a volume that does not have any snapshots, if SIS is enabled on the volume, fractional reserve behaves as if a snapshot is always present
  • Therefore, the fractional reserve will be honored and the volume will appear to have less space available
  • This can be problematic, as LUNs can potentially go offline if the volume fills up and no overwrite space is available
  • When portions of the space on the LUN provisioned to the host referenced in the above sentence get marked as read-only, that space must still be provided to the host for random metadata writes, hence the growth of used fractional reserve that can go UP to 100%


  • If a 5Gig LUN has 2Gig written to it when the snapshot is initially taken, the used space in the containing volume will show as 7Gig
  • This is caused by a reserve of 2Gig held for OS overwriting on the snapshot lock of those 2Gig blocks
  • If a 1Gig change occurs after the last snapshot was taken on the LUN but the used space stays the same, 3Gig will now be reserved and the used space shows as 8Gig
  • In summary, the system will continually compensate to ensure that the OS will have perceived writability to the full 5Gig when writing to the LUN
  • This will even occur when used space equals 4.9Gig according to the host OS
  • The host OS with one snapshot and no change would show used space at 9.9 Gigs
  • With 1Gig of change and another base snapshot, 10.9Gig would show as used
  • If 3Gig of change continually occurs on a 5Gig LUN ( 4.9 gigs used on the OS level) over the course of a snapshot's lifetime, then the minimum advisable space would be 10Gig + 3Gig = 13 Gig
  • This can be tested with the following process: 
  1. Created a volume with a snap reserve of 0
  2. Create a LUN and right-click on it in My Computer to get its size
  3. Convert the LUN's size as well as the used and free space to KB
  4. Place a specific amount of data on the LUN and convert it to KB
  5. Run df /vol/<volname> to see what is expected in utilization
  6. Take a snapshot and immediately run df /vol/<volname> again.  Although the snapshot takes up no space, the used space on the volume will have increased by the amount that was placed on the LUN
  7. Change the data on the LUN.  Actual change as opposed to deletes will be necessary so that original block pointers are left behind
  8. Run df /vol/<volname>. The LUN + the overwrite reserve + the amount of space used by the changed snapshots will be visible
  9. Take a new snapshot and Run df /vol/<volname> again.  Now the LUN + the overwrite reserve + the amount of space used by .snapshot will appear as used space
  10. When a full schedule of snapshots has cycled through, run the snap delta command to get a good idea of how much extra space is needed on the volume, specifically:
    • 100% extra if the LUN exists
    • beyond the 200% of the expected size of the LUN in free space if it has yet to be created
  • Remember that snapinfo directories fill up with file data quickly
    • They will also change quickly depending on the number of online backups required
    • Therefore the delta may be higher than expected for the containing LUN
  • Also, the fractional reserve can be tweaked to a lower amount, but in the event of host overwrites meeting read-only blocks, LUNs can be abruptly taken offline

Additional Information

  • Run the below command to change the fractional reserve to 0%: 

::> volume modify -fractional-reserve 0 -vserver <svm-name> -volume <vol-name>


NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.