Zero Out Free Space

by Bob Plankers on December 10, 2013

in Best Practices,Cloud,System Administration,Virtualization

This is post #10 in my December 2013 series about Linux Virtual Machine Performance Tuning. For more, please see the tag “Linux VM Performance Tuning.”

When we talked about the rationale behind storing logs centrally one big reason was thin-provisioned virtual disks. Those disks grow over time because filesystems on a virtual machine currently have no way to tell the underlying storage that they’re done using certain blocks on disk.

There is a way to make these VMs thin again, and I wrote about it as step 9 in my guide to preparing Linux Template VMs. In short, we run a script on the VM that writes zeroes to most of the free space on the VM:

#!/bin/sh

# Determine the version of RHEL
COND=`grep -i Taroon /etc/redhat-release`
if [ "$COND" = "" ]; then
        export PREFIX="/usr/sbin"
else
        export PREFIX="/sbin"
fi

FileSystem=`grep ext /etc/mtab| awk -F" " '{ print $2 }'`

for i in $FileSystem
do
        echo $i
        number=`df -B 512 $i | awk -F" " '{print $3}' | grep -v Used`
        echo $number
        percent=$(echo "scale=0; $number * 98 / 100" | bc )
        echo $percent
        dd count=`echo $percent` if=/dev/zero of=`echo $i`/zf
        /bin/sync
        sleep 15
        rm -f $i/zf
done

VolumeGroup=`$PREFIX/vgdisplay | grep Name | awk -F" " '{ print $3 }'`

for j in $VolumeGroup
do
        echo $j
        $PREFIX/lvcreate -l `$PREFIX/vgdisplay $j | grep Free | awk -F" " '{ print $5 }'` -n zero $j
        if [ -a /dev/$j/zero ]; then
                cat /dev/zero > /dev/$j/zero
                /bin/sync
                sleep 15
                $PREFIX/lvremove -f /dev/$j/zero
        fi
done

This will balloon the VM out to it’s full allocation. Then, if you use Storage vMotion to move the VM between datastores on different arrays (or within the same array with VAAI off), and specify thin provisioning (instead of “same as source”) the datamover will extract all the zeroed out portions and make the VM thin again. And once you are done you can instruct VMware to use UNMAP commands to reclaim space on your array, if your array supports the VAAI UNMAP commands.

Another approach, if you have an array that deduplicates, is to make your VMs thick-provisioned instead, zero out their free space, and let the array do the rest of the work. This might be a better approach depending on your chargeback/showback strategy.

Either way there are considerations to make. Size of the fully-expanded VM may be an issue. Replication and backup might be an issue, perhaps needing temporary suspension. SAN traffic might be an issue, since VAAI cannot be used to re-thin the VMs. Heck, even chargeback might be an issue. If you are seeking the most fully-optimized, thinnest-provisioned disk, though, this is a way to do it.

Under Windows a similar effect can be had using the sdelete utility.

Comments on this entry are closed.

Previous post:

Next post: