Is it user (my) error, or has VC disk space overhead increased dramatically?
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hi folks,
(( Just signed up; first post here. Big thanks to maintainers and contributers for VeraCrypt. ))
I have a 3 year old VeraCrypt container (32 GB) that is running out of space, so I created a new larger VeraCrypt container (40 GB) to replace it, mounted both volumes, and copied the entire contents from old to new. I've done this with various containers in the past and never had an issue, or been surprised by the result.
This time, after the copy, the 40 GB volume has LESS free space than the 32 GB volume, despite the contents being identical. Windows properties shows:
Original volume: 29.2 GB used of 31.9 GB (free space 2.12 GB)
New volume: 38.1 GB used of 39.9 GB (free space 1.82 GB)!!
That's an increase in overhead from 7% to 40%.
I don't think this can be blamed on exFat, since both volumes are exFat and the contents are identical. In fact, I can't identify anything different except the VeraCrypt version used to create each container.
I've repeated the process several times, including downgrading to VC 1.26.7, copying the contents to an intermediate regular windows (NTFS) folder first, copying with BeyondCompare as well as windows explorer. Results are always the same.
Is 40% file space overhead the new normal, or am I doing something wrong, or is this an issue in the current VeraCrypt? Thanks for the help.
Details:
OS: Windows 10 Pro x64 22H2 (up to date).
VeraCrypt: 1.26.29.
Original VeraCrypt volume created 2023-09.
Properties:
encrypted file container
standard volume
AES(Twofish)
sha512
Size = 32 GB
large files - yes
exFAT
New VeraCrypt volume created today (1.26.29)
Properties:
EXACTLY same as original, except:
Size = 40 GB
sha512 --> SHA512-PBKDF2 (is this more than just a rename?)
Try this Powershell command for both containers:
(with the 'E' replaced with the appropriate drive-letter)
On Thursday, September 24th, 2026 at 7:52 PM, Al Braun al-dot@users.sourceforge.net wrote:
Get-Volume doesn't find or show mounted VC volumes. (Neither does windows disk manager). I've just created and mounted a tiny NTFS volume to test, and it doesn't show up either. I don't know if this is some odd setting of my OS I don't know about, or true for windows 10 pro in general.
In any case, the allocation unit size for all the VC containers I've created will be whatever the default is/was - I've never explored non-default settings.
Just use any other tool to get the cluster size, iirc Windows ups it from 32 to 128 KB somewhere around 32GB drive size.
If those values differ, you can reformat the new container using the same cluster size.
On Thursday, September 24th, 2026 at 9:06 PM, al-dot al-dot@users.sourceforge.net wrote:
Ah. Much obliged @RichardH - a change in the default allocation unit size is exactly what's going on here. Finding the allocation unit size of a VC volume is quite opaque (my searches only turn up solutions for physical disks - but maybe that's just my search skill).
Doesn't matter. To test, I've made another volume and set the alloc unit size to 1 kB. The same file contents on that volume take just 27.4 GB - less than the original. So that's QED.
Excellent :-)
According to https://superuser.com/a/1724928/3386255
chkdsk e:should show the allocation unit size too, I assume that works for a mounted container too (no Windows VM to test myself).On Thursday, September 24th, 2026 at 10:04 PM, al-dot al-dot@users.sourceforge.net wrote:
A final comment (feature request?)
It seems the "default" setting in the VC volume creation wizard isn't VC setting the value, but VC deferring to windows to choose the size? That isn't clear from the interface, and not the expected behaviour for a "default" setting in an app.
Also, it would be nice if the UI showed the alloc unit size of mounted volumes, in the listbox and/or in the "volume properties" dlg.
But yes, right at the bottom of the priority queue...