Storage efficiency not passing on savings to Windows 2008 R2 Server


(If I've posted in the wrong place, please say!)

The scenario we're seeing is the following:

- Created a 4TB LUN on a FAS2240-4 Netapp

- Created a single volume within that LUN @ 3.5TB

- Turned on Storage Efficiency on the volume (Automatic), no compression.

- Connected the LUN to a Windows Server 2008 R2 server with SnapDrive 6.5

The problem is simply that Windows' view of the volume is that pre Storage Efficiency and thus the whole drive appears full to Windows. Netapp however claims there's 1.7TB space on the volume.

Some other salient information:

- We're running Netapp Software version 8.1.2 7-Mode.

Any help gratefully received; please also let me know if you need more information.

Rich Maclannan

Re: Storage efficiency not passing on savings to Windows 2008 R2 Server

First, I think you reversed your use of the term "lun" and "volume" in your first two bullet points.  Correct me if I'm wrong, but what I think you meant to say is you created a 3.5TB LUN inside the 4TB volume.

Space Efficiency (deduplication) saves you space on the back end (the storage end).  If you created a 3.5TB Windows lun and you put 3.5TB worth of files into it, then you've used up all the space from the host's point of view.  You might see less space used on the storage side.  Additionally, a lun is a block storage device, and I would recommend that you read up on that and on "space reclamation" because eventually you will see your lun fill up to 100% utilization on the backend (even if your hosts sees more free space) and you'll wonder why that is.

So, bottom line is, if your Windows host sees the drive is full, then you need to increase the lun size (and therefore the volume size) or look into other alternatives.

Re: Storage efficiency not passing on savings to Windows 2008 R2 Server

Thanks for the quick answer. You're right - the LUN and volume descriptors were the wrong way round. Sorry!

It would be helpful if there were some way of the Netapp cleverly passing back to the Windows host that it had actually freed up space by mapping identical blocks, and only reporting an "out of space" condition when the LUN had filled up its space with non-identical blocks. But I'll leave the discussion there; it's not immediately obvious how that could be done.

Rich M