LEFTHAND SAN - Reclaiming Space - Say it isn't so!

[kiwiiwik]

Hi,

I hope that the experts here can provide some clarity based on a simple specific example. I have spent an hour looking though messages on this board and have formed an opinion - I can't quite believe it is correct though:

I am a consultant and have a client who has a LH San installed and maintained by an MSP. The MSP is pressing them to add another two nodes to their 5 node SAN to alleviate disk space issues. I don't believe adding more nodes is the correct solution.

Consider this example:

• The SAN is used for storage of files created by forensic analysis software which runs on a Windows 7 64bit workstation.
• The disk volumes on the SAN are presented as ISCSI targets. The volumes are thnn provisioned.
• One of these disk volumes  (Q:) is seen in Windows explorer as a 5TB volumes and is shown as 2.5TB used 2.5TB free.
• In the chart provided by the MSP they show that this volume is "consuming" 10.23TB of SAN space out of a total available of 31.8TB across the SAN.

Q1: How can my client recover the lost 5.23TB and return it to the available pool?

Q2: From what I have read on the board the only solution is to backup the entire volume to the Windows 7 workstation then create a new volume on the SAN and restore it. Is that correct? (we have already started this process using Shadowprotect desktop and cheap SATA 4TB disks.

Q3: Furthermore the MSP says that if we were to add say 2TB of data to the Q drive as it stands it would push the actual consumed space out to around 12.2TB - ie it would'nt overwrite any of the aready consumed space. That implies that regardless of housekeeping/deletion of files at the Windows 7 level the size of the consumed space on the volume will continue to grow. Is that correct?

Q4: The end user is using a desktop operating system. Is that causing issues with the SAN disk managemenent processes? I would have thought the OS was largely irrelevant.

Q5: Is the nature of the software the client is using - writing tjhousands of small files, then deleting them as forensic cases come and go fundamentally unsuited to SAN infrastructure?

FYI: The SAN is shared with the clients production Hyper-V network.

Thanks for your time and hopefull assistance. From a noob perspective this appears to me to a fundamentally broken implementation of SAN software - so I am hoping that I  have missed something??

Cheers,

Rod.

[Sbrown]

1. We've been asking for thin reclamation for a while....

2. turn off defrag and optimize ;) you'd be surprised how many folks don't realize these tools get enabled (p2v/v2v/upgrades)

3. you have some options - deduplication (part of hyper-v 2012/r2) - there may be a chance the same files are being stored (deleted or not) and dedupe can help!  Microsoft has a tool to estimate dedupe gains.

or

4. Filesystem compression.

The main problem with thin reclamation is that the current SATA protocol has no way to trim sectors with Native Command Queue in the current SATA 3.

So there are hardware approaches: Hardware zero thinning (3par!), compression and dedupe (storeonce!), and operating system (2012/R2/7/8) that can help.

Everyone is cheering on for Thin Reclamation via SATA-TRIM or SCSI_UNMAP or perhaps deduplication or a manual function! I've been waiting years! (i am a customer!)

So yeah. Thankfully storage is cheap nowadays, and running Thick in some cases is not a bad idea.

The data is not lost, it is just "marked for used" by that ISCSI lun.

Back before I decided to just "thick it out" - I would SDELETE the volume to zero it out, svmotion it to another (VSA?) and then nuke the LUN, create a new LUN and svmotion it back. Could be automated perhaps :)

YES - we think it is fundementaly broken!!

I'd definitely look into compression and dedupe if that is acceptable and "thick it out!".

The new storevirtual 11 has Adaptive Optimization !! :) Free for VSA! you could just attach some 4TB SAS (RE4) nearline drives for this guy and give him his own private idaho. Great use for VSA! :)

We were hoping for thin reclamation - but ask yourself this - If we have Thin Reclamation and Adaptive Optimization, what is the point of buying a 3Par when my $399 DL180 12-core L5639 12/14/25/27 drive junker [ebay search: l5639 hp] would decimate the 3PAR ASIC with 12 cores/24 threads of westmere yummyness.

[hint: nexentastor or napp-it or freenas SMB3 mount with dedupe/compression connected to lefthand via ISCSI]

[kiwiiwik]

Thanks for your detailed response SBrown.

Just to clarify, if the end user was to run sdelete on the Q: volume that has (as far as windows 7 is concerned) approx 3TB of unused space, this would have no beneficial effect on the Consumed Space on the SAN - no "Zero-Page-Reclaim" process will be run at the SAN level?

So, It appears that the only way to return space to the pool is to do a complete backup - delete the volume at the SAN level - create a new volume - restore the data back into it . Is that correct? 

If the new volume is "thick Provisioned" does the space consumed cap at the size of the volume?

I still cant figure out why every lefthand volume does'nt inexorably grow in space consumed as files are created and deleted...

Cheers.

[Sbrown]

Copy on write

Recycle bin versus shift-delete

Shadow copies.

I am saying, the feature that 3PAR has, lefthand does not.

The simplest form of dedupe/compression would be to just handle zero pages.

Unless something has recently changed, its the achilles heal of the product! :(

[Al_S]

We are running into the same issue where vSphere shows 1.5TB available and the SAN shows 170GB.  I called HP and they told me to delete the 2 volumes and start over.  Are you kidding me?!!  That's a ton of work.  We are in the process of deciding what to do.  I'm thinking of dumping Lefthand and going with something else.  This is just ridiculous.

[Sbrown]

It's not that much work with vcenter if you have enough space to thin out.

One option is to sdelete the vm's to thin them out,  you could MIGRATE to local storage[vsa,das], detach/delete the old lun [specific steps in order!], create a new lun, then migrate back to the new lun.

Maybe even someone has a script to ZERO the lun , shrink/expand it.

That would be really nice if someone could share that.

If they add dedupe/compress (all zeroes only) to re-thin, well you might as well then call it the 3PAR VSA :)

Would step on some toes there.