Very important concept in the NetApp FAS.好難用英文描述，用中文好了……
一個LUN對於NAS儲存系統來說是單一的檔案，這個檔案會有一個inode對應至其所擁有的blocks。當這個LUN所在的volume進行snapshot後，會將該volume的metadata(inodes and others)複製一份，當LUN裡頭資料有變動時(block變動)會被WAFL將寫入的動作轉導向(Redirect-on-write)而寫至available的區塊，然而當LUN在被填滿資料時進行snapshot後，若volume剩餘空間<LUN所擁有的空間時，持續寫入新的資料可能會造成Initiator及Target對於LUN可用空間認知上的落差，而導致寫入失敗，當NA認知到LUN所在volume已被寫滿時，NA會自動將該LUN offline處理，此時則必須vol size擴大volume空間以重新mount該LUN。
寫了這麼多，很難懂? 舉個例子
情境一：1.25TB Volume上建一個750GB的LUN，並在mount後盡可能將該空間塞滿資料，create snapshot，結果? 失敗!
情境二：1.25TB Volume上建一個400GB的LUN，並在mount後盡可能將該空間塞滿資料，create snapshot，結果? 成功! df -Vh結果? 已使用800MB!
情境一：假若snapshot成功，750GB的LUN格式化，並重新塞滿資料，會發生什麼事情? 主機上會認為自己可用750GB而嘗試寫入，但storage上? 1.25TB扣除750MB僅剩500MB可用作snapshot後的available blocks，因此為了預防這種情形發生，Fractional reserve option誕生!
情境二：default fractional reserve 100即為保留100%目前資料空間作為reserve用，以避免上述情形發生!