This project has moved and is read-only. For the latest updates, please go here.

"Size on Disk" much larger than original files


Hello. I have run several tests while trying to encrypt about 205GB of data (mostly JPG, TIF, and PDF files). I chose this test grouping as its a sub-set of a much larger overall archive I wish to encrypt -- which is about 6.2TB in size.

If I create a standard "encrypted file container" volume with an initial size of 244GB (the original 205GB test batch plus an increase of 20% for 'extra' room -- just in case) -- everything seems to work Okay by choosing all of the default options in the Creation Wizard. The total disk space used was near 237GB -- about 15% more than the un-encrypted file size.

However, if I create a larger encrypted file container volume -- 2TB, for example -- and encrypt this exact same 205GB grouping of files, it now consumes 0.97TB of space -- a nearly 470% increase in file size! Nothing was changed except for the size of the underlying container. All of the 'default' settings were chosen in the Creation Wizard.

Why does the amount of space consumed dramatically increase when creating an encrypted file container volume that is very large?

file attachments


MapleLeaf77 wrote May 16 at 6:38 PM

The "File System" that was chosen, by the Wizard as its default, was exFAT -- in both the 244GB container test and the 2TB container test.

MapleLeaf77 wrote May 16 at 6:55 PM

And, the encryption was AES/512

AdrianKIT wrote May 16 at 8:30 PM

What happens if you repeat your experiments, specifying a cluster size of (say) 1MB?

I would advise that one should never choose a 'default' cluster size when formatting (disks, or veracrypt volumes); first of all, this will vary by the size of the container (disk, or veracrypt volume), and the default size might bear no sensible relation to the typical size of files to be stored therein.

The arithmetic is pretty simple in principle eg 1000 files 1.9MB each, cluster size 2MB, approx size on disk 2000MB; 1000 files 1.9MB each, cluster size 32MB, approx size on disk 32000MB, 16 times as much!

Each file (or part thereof) smaller than the cluster size occupies the whole cluster (as far as the file table is concerned); the only downside of small cluster sizes is the file table takes up a bit more space, because it has more cluster to deal with.

MapleLeaf77 wrote May 16 at 9:06 PM

Thank you for this guidance. I'll perform several tests of different (and smaller) cluster sizes. What if I know we will encounter some files in the 2GB-4GB range (an possibly a few rare files over 4GB)?

AdrianKIT wrote May 17 at 7:52 AM

I don't think it's sensible to skew your cluster sizes to take account of a few very large files. As it happens, I don't use exFAT, only NTFS where I can, and Fat32 where I have to for cross-device compatibility reasons, but whatever the size of my 'containers' (standard disks or veracrypt volumes) I always specify a cluster size of 4KB!

As I've said, this increases the size of the file table somewhat, (and also will slightly increase read/write times, since there are more cluster records to be consulted/created on the file table during such operations), but any alternative just wastes disk space. My 'sizes on disk' are pretty close to my total file sizes!