Microsoft Virtualization Discussions
Microsoft Virtualization Discussions
I'm working with a support engineer now to figure this out, but I want to ask you guys also.
Filer: FAS2240 running 8.1.1 7-Mode
Windows OS: Windows 2008 R2
I'm running this on my Exchange 2010 server for the TLOGs volume mount point.
PS C:\Windows\system32> Get-NaHostDisk
HostDrivePath Disk Size ControllerPath
------------- ---- ---- --------------
C:\ 0 100.0 GB
1 100.0 GB
C:\Exchange2010\Databases\ 2 1.0 TB WST-NETAPP01:/vol/exch2010_mbox01_db/qtree01/mbox01_db01
C:\Exchange2010\TLOGs\ 3 1004.0 GB WST-NETAPP01:/vol/exch2010_mbox01_tlog/qtree01/mbox01_tlog01
C:\Exchange2010\PublicFolders\ 4 99.6 GB WST-NETAPP01:/vol/exch2010_mbox01_pubfolders/mbox01_pubfolders
I ran the following command:
Measure-Command { Invoke-NAHostVolumeSpaceReclaim -Path C:\Exchange2010\TLOGs\ -confirm:$false -Unmapsize 2MB } | select TotalMinutes,TotalSeconds
The first time took 37 minutes and, according to Windows, I went from having 25GB free to 828GB free.
However, nothing changed on the filer ... I still only have 23GB free.
Filesystem total used avail capacity Mounted on
/vol/exch2010_mbox01_tlog/ 1069GB 1045GB 23GB 98% /vol/exch2010_mbox01_tlog/
Is this normal behavior? Am I supposed to see the free space on the LUN like I do in Windows?
How does this affect snapshots? According to Best Practices, SME puts all of my backups in the TLOG volume so I really need to make sure there's always room available there.
Solved! See The Solution
Hi Chris,
Do you see the free space in the LUN listing? After running the space reclaim, the free space seen by ONTAP (for the LUN) should closely match the free space seen by Windows. The free space at the volume level in ONTAP may not match initially because there are probably snapshots of the LUN from before the space reclaim (especially if the snapshot reserve is set to 0%). Eventually, when those snapshots get old and are deleted, you will see a decrease in reported usage at the volume level.
For example, here is the LUN free space before and after a reclaim:
PS> Get-Nalun /vol/powershell/reclaim
Path TotalSize SizeUsed Protocol Online Mapped Thin Comment
---- --------- -------- -------- ------ ------ ---- -------
/vol/powershell/reclaim 50.0 GB 2.1 GB windows_2008 True True True
PS> Get-NaLun /vol/powershell/reclaim
Path TotalSize SizeUsed Protocol Online Mapped Thin Comment
---- --------- -------- -------- ------ ------ ---- -------
/vol/powershell/reclaim 50.0 GB 89.3 MB windows_2008 True True True
-Steven
Hi Chris,
Do you see the free space in the LUN listing? After running the space reclaim, the free space seen by ONTAP (for the LUN) should closely match the free space seen by Windows. The free space at the volume level in ONTAP may not match initially because there are probably snapshots of the LUN from before the space reclaim (especially if the snapshot reserve is set to 0%). Eventually, when those snapshots get old and are deleted, you will see a decrease in reported usage at the volume level.
For example, here is the LUN free space before and after a reclaim:
PS> Get-Nalun /vol/powershell/reclaim
Path TotalSize SizeUsed Protocol Online Mapped Thin Comment
---- --------- -------- -------- ------ ------ ---- -------
/vol/powershell/reclaim 50.0 GB 2.1 GB windows_2008 True True True
PS> Get-NaLun /vol/powershell/reclaim
Path TotalSize SizeUsed Protocol Online Mapped Thin Comment
---- --------- -------- -------- ------ ------ ---- -------
/vol/powershell/reclaim 50.0 GB 89.3 MB windows_2008 True True True
-Steven
After speaking with support it turns out the problem was my lack of knowledge on how a LUN works. Before this, everything I've done has been with NFS volumes. What I learned was that a LUN will never shrink in size. Once it's grown, there's no reclaiming that space. The dangers in that is making sure you now have enough space in your volume to maintain your snapshot retention policy.
Shrinking the NTFS volume inside the LUN, however, worked perfectly.
I've shrunk luns before with snapdrive for exchange 2007 on a cluster. It's not optimal and only works on certain scenarios.