Checking Hole Punching

Hole punching lets you mark a range of bytes inside a file as “unwanted” so the file system can release the underlying storage blocks. The file’s apparent size stays the same, but the on-disk footprint shrinks. If you are working with sparse files, virtual machine images, or large data sets where reclaiming space without rewriting the file matters, confirming that your kernel and file system actually support the operation is a quick win.

Creating a Test File

Start by creating a 100 MiB file with no holes:

$ dd if=/dev/zero of=punch bs=100M count=1

You can verify that the file occupies its full size on disk:

$ du -h punch
100M    punch

Punching a Hole

Now punch a 10 MiB hole starting at the 2 MiB offset:

$ fallocate -p -o 2M -l 10M punch

The file’s logical size does not change (you can confirm with ls -lh), but the disk usage should drop if your kernel and file system support the FALLOC_FL_PUNCH_HOLE and FALLOC_FL_KEEP_SIZE flags:

$ du -h punch
90M     punch

Verifying Support

If the du output still shows 100 M, the operation likely failed silently. A few things to check:

• Kernel version. The fallocate punch-hole support was merged upstream in Linux 2.6.38. Older kernels (for example, a 2.6.32-based distribution) may or may not have the relevant patches back-ported. Run uname -r to see what you are running.
• File system support. Not every file system implements the punch-hole flag. Ext4, XFS, Btrfs, and tmpfs all support it. Some older or network file systems do not.
• Permissions. You need write access to the file and the file must not be opened for writing by another process.

Run man fallocate for the full list of flags and file system requirements.

Quick Reference

If the test passes, you can confidently use hole punching in production workloads to reclaim space in large files without copying or truncating them.

• Technology
• How-To

• SysAdmin