Array Setup and Networking
Showing results for 
Search instead for 
Did you mean: 

Reclaim space quickly (sdelete alternative)

Occasional Visitor

Re: Reclaim space quickly (sdelete alternative)

I apologize Graham.  I somehow forgot about this and never followed up.  I'm in the midst of needing to run this script again and unfortunately I can't find my original script that prompted this post.  I'm going through my notes and will revisit creating a script you may be able to try in your environment if you still need it.

Edit:  I have edited my original post and attached my copy of the script.

Frequent Advisor

Re: Reclaim space quickly (sdelete alternative)

Thanks and the script worked for me. But the space reclaimed from the volume was taken back by the snapshot which didn't really save me anything.

Respected Contributor

Re: Reclaim space quickly (sdelete alternative)

It will, when the snapshot is deleted.

If you do not have any snapshot schedules defined then it will take an hour to disappear. Don't worry you get the space back

New Member

Re: Reclaim space quickly (sdelete alternative)

Thank you very much for this script! I have been using this for a couple of years now, pretty successfully. I have used it on other brands of SANs also with excellent results.

Recently I ran into a problem where the "write zeros until less than 1 GB left" was causing some VMs to "pause". This is on Hyper-V 2012 R2.  Hyper-V polls for free space regularly and if the free space falls under 2 GB it warns. When the free space falls under 200 MB it pauses VMs. To alleviate the problem, I have changed this line to 3 GB

while ((gwmi win32_volume | where {$ -eq "$FilePath"}).Freespace -gt 3221225472) {

Sure, I will have the last 3 GB not zeroed out and not reclaimed but I can live with that. What I cannot live with is to come into the office on Monday and see some of the production VMs paused (causing outage).

PS: no fault of the script here, just how Hyper-V works.

Again, thanks for the excellent script!

New Member

Re: Reclaim space quickly (sdelete alternative)

Well, I am replying to my own post.

While setting the minimum space left to 3 GB prevents Hyper-V VMs from going into a paused state, I still get alerts from SCOM saying:

The cluster shared volume CSV 12 Near Line mounted on C:\ClusterStorage\Volume12 is running out of disk space. The value that exceeded the warning threshold is 1% free space.

I wonder if the Get-WmiObject win32_volume can output a percentage and then we can make somehow make sure the space in the CSV (cluster shared volume) does not fall below 1%

Sorry, I am not VERY good with scripting, so asking this question here.


Re: Re: Reclaim space quickly (sdelete alternative)

Hey Matthew,

I've reworked your script to include multithreading as well as a couple other tweaks.

  • By default the script will run 2 threads but you can change it by specifying -maxthreads when you call it.
  • The script will write 10GB files ($fileSize) and stop once there is less than $fileSize+2GB free. This is to prevent the scenario where the run loop finds exactly 10GB free and decides to fill it up on a production volume, giving a high chance of breaking other applications.
  • The script has been modified to work with Mount Points while ensuring they won't get filled up (previous point)
  • There's a progress bar (this shouldn't be the part I'm most pleased with, right??)

This is of course free for anyone to use and I welcome any bug reports. I've tested it on my own desktop and several servers but obviously haven't put it through rigorous QA so use it at your own risk.

To call the scripts, use

ZeroAsync.ps1 <path> [-MaxThreads <numThreads>]

So "ZeroAsync.ps1 E:" or "ZeroAsync.ps1 C:\myMountPoint -MaxThreads 4" or something like that.


New Member

Re: Reclaim space quickly (sdelete alternative)

Thank you very much for this.  I will keep this in my toolbox for future reference.  I just had to reclaim about 1TB on an old fileserver that I used VMware Converter to clone the machine with new disk sizes.  Wish I had this info back then.