2015-07-22 06:33 AM
Could someone clarify something for me. I understand the need to reclaim space on thin provisioned LUNs using SnapDrive's space reclaimer. Is this a requirement for thick provisioned LUNs or will running it only fix the space reporting in System Manager. As an example - a 10Tb thick provisoned LUN is presented to a physical Windows server and mapped to a drive. 6tb of data is written to the LUN, and Windows and System Manager both agree that there is 4Tb free. All of the data is deleted. Windows sees 10Tb free and System Manager still sees 4Tb free as it has no way of knowing the blocks have been marked as deleted. Expected behaviour. Now if we write another 6Tb to the volume will there be space? The LUN will eventualy show 100% full, but after this will Windows quite happily carry on writing to the drive?
I could test this but I wondered if anyone had any real world experience. In my organisation we have a process regularly run Snapdrive space reclaimer on thick provisioned LUNs and I am wondering if we need to (other than getting system manager to report correctly)?
Solved! SEE THE SOLUTION
2015-07-22 06:41 AM - edited 2015-07-22 06:42 AM
The answer is a bit complicated. In general, "thin provisioned" implies "no space reservation", so it may happen that volume runs out of space because it will be filled by other data (e.g. other LUN, snapshots etc). See TR-3483 for detailed description of LUN space management on NetApp.
P.S. I edited reply and corrected TR number.
2015-07-22 06:45 AM - edited 2015-07-22 06:46 AM
What I'm wondering about is if the LUN is Thick provisioned.
But thanks for the pointer - the answers may be covered in there
2015-07-22 06:51 AM
It's still complicated I do not really know what combination of settings System Manager is using for "thick provisioned"; if we speak about space gurantee == volume and fractional reserve == 100% then you should always have enough space to (over-)write full LUN size.But note that under some conditions NetApp may not honor volume space gurantee ...