- ONTAP 9
- Data ONTAP 7 and earlier
All of the space disappeared on a LUN-containing volume after the first snapshot. 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.
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%.
For example, 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 used space stays the same, 3gig will now be reserved and 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 minimum advisable space would be 10Gig + 3Gig = 13 Gig.
This can be tested with the following process:
- Created a volume with snap reserve of 0.
- Create a LUN and right click on it in My Computer to get it's size.
- Convert the LUN's size as well as the used and free space to KB.
- Place a specific amount of data on the LUN and convert it to KB.
- Run df /vol/<volname> to see what is expected in utilization.
- 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.
- Change the data on the LUN. Actual change as opposed to deletes will be necessary so that original block pointers are left behind.
- Run df /vol/<volname>. The LUN + the overwrite reserve + the amount of space used by the changed snapshots will be visible.
- 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.
- 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 freespace 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-read only blocks, LUNs can be abruptly taken offline.
Run the below command to change the fractional reserve to 0%:
::> volume modify -fractional-reserve 0 -vserver <svm-name> -volume <vol-name>