VDI-file size increase

[ecfs]

After struggling for days I can't find the solution and can't find a hint in the net...

The effect I have on two different hosts:
1) Ubuntu 12.04 server - VirtualBox 4.1.12_Ubuntu r77245 - no Guestadditions
2) Xubuntu 14.04 - VirtualBox 4.3.28 r100309 - with Guestadditions

The Guest:
Ubuntu server 14.04 - with Guestadditions - 512 MB RAM - VT-x/AMD-V, Nested Paging - SATA-Controller - AHCI - 1 Port - HDD: VDI - virtual size 8 GB - actual size 3,07 GB - dynamic

I currently have the effect that my VirtualBox vdi-file is growing much more than it should. It is growing by several 100 MB within 24 hours even if the virtual machine is only started in headless mode - no user logged in, no other action within the machine. I did several tests within the last week - what I found is that the file is growing always by 1 Mi (mebi - 1.048.576 Bytes) or x times 1 Mi. It seems that every write action is done into a (or several) new 1 MB block(s).
I found further that I can compress the vdi file again to nearly it's original value by the normal means (zerofree / VboxManage ...--compact). I checked all possible files (e.g. /var/log, /mail etc) several times and can't find a file being extremely big or growing by the size the vdi file is growing. And if it would exist it would have been impossible to compress the vdi file ...

As I had the suspicion that it might have to do with Webmin - what is not true as I know in the meantime - I did the following:

Since yesterday evening I'm running 24 hours test with 2 identical VB Guests. The only difference between the two guests is that in the first one the webmin service is stopped and in the second one running:

Time - Size of vdi-file - increase (Bytes) - increase divided by 1 Mi (1.048.576 Bytes)

without Webmin
02:59:00 - 3.515.875.328
03:04:00 - 3.696.230.400 - 180.355.072 = 172 Mi (increase / 1 Mi)

06:34:00 - 3.696.230.400
06:39:00 - 3.697.278.976 - 1.048.576 = 1 Mi
06:44:00 - 3.915.382.784 - 218.103.808 = 208 Mi

no changes in the size of the vdi file since 06:44 (Europe, Berlin time).

What happens at 03:00 (in both boxes) I know - its a cronjob (sudo apt-get update && apt-get upgrade), what happens between 6:43 and 6:44 I have to find out

with Webmin
20:43:00 - 3.424.649.216
20:48:00 - 3.536.846.848 - 112.197.632 = 107 Mi

02:43:00 - 3.536.846.848
02:48:00 - 3.744.464.896 - 207.618.048 = 198 Mi

02:58:00 - 3.744.454.896
03:03:00 - 3.872.391.168 - 127.936.272 = 122,0095367432 Mi

06:33:00 - 3.872.391.168
06:38:00 - 4.004.511.744 - 132.120.576 = 126 Mi

08:48:00 - 4.004.511.744
08:53:00 - 4.010.803.200 - 6.291.456 = 6 Mi
08:58:00 - 4.090.494.976 - 79.691.776 = 76 Mi

13:43:00 - 4.090.494.976
13:48:00 - 4.091.543.552 - 1.048.576 = 1 Mi

14:53:00 - 4.091.543.552
14:58:00 - 4.104.126.464 - 12.582.912 = 12 Mi

as you can see with Webmin service running much more activity and therefore a bigger increase of the vdi file size.

By the way - I gave you the details of the guest higher up in my post - "actual size 3,07 GB" - I copied this from the guest with started Webmin service a few minutes ago - now compare this value with the actual size of the vdi (4,1 GB) ...

Furthermore the protocols show that the increase of the file is going in 1 Mi steps or x time 1 Mi (last column). Jamie Cameron (thanks to him) from the Webmin team gave me following hint: "Webmin does some background status collection every 5 minutes, which writes to files in /etc/webmin/system-status. Perhaps that is the cause? It just re-writes the same file over and over though." and "If VirtualBox is tracking modified blocks as part of some kind of filesystem journal, that would explain it."

As I'm not so deep in file system questions I can't fully understand the consequences of his hint...

Can somebody help me to understand what's going on here? Is it a kind of bug or misconfiguration I unknowingly made? This is not my first Linux guest I created with Virtual Box on a Linux host but it is the first time that I see this effect...
But for the application I have to get running within this guest it is absolutely necessary that the vdi file remains as small as possible (for backup and transfer reasons) and so I can't live with this effect and I can't compress the vdi file every 24 or 48 hours... So I need a solution to avoid this effect.

Thanks for any hint.

[mpack]

The VDI grows because some task inside the guest OS is writing to new areas of the disk. VirtualBox has no control over that. You should check what guest tasks are running. I'm thinking defrag etc.

Yes, the unit of allocation in a VDI is 1MB.

I am quite sure that there is no VirtualBox bug in this area. It is commonplace when a VM is new that the disk will grow quickly at first. However as time passes the chance that a completely new sector will be written to decreases almost to zero, unless the guest has a really weird filesystem that actively avoids reusing sectors.

[ecfs]

Hello mpack,

thanks for your answer.

The file system of the guest is a normal ubuntu ext4 - so nothing unusual.

If it is normal that the vdi file grows in the beginning of a guest history and it starts with e.g. 2.7 GB at which size - according to your experience - the rapid grows will probably stop?

Nevertheless I will check the guest tasks ...

Regards Christian

[mpack]

It's impossible to predict when the growth will stop. It entirely depends on your usage patterns and the list of apps running in the guest. In my case an XP guest with a 32GB (logical drive) is still only 1.8GB after years of use! Another is at 10GB. But, I always disable background indexing etc.

I also know that if some one off task (or a mistake) made the VDI grow excessively then I can always compact it again. CloneVDI is IMHO the most convenient tool for this - on Linux hosts you need to run it under Wine.

p.s. In fact a dynamic VDI starts off with 0 bytes allocated (ignoring the fixed size header for this discussion). Every expansion is due to a guest write. If the file is 1.7GB then the guest wrote at least 1.7GB of data to previously unused sectors.

[ecfs]

OK - as I see now I have to live with this effect and watch carefully the development of the vdi file. Furthermore I have to keep an eye on the tasks running and to avoid everything unnecessary. And - if necessary - I have to compress the vdi file.

Thanks very much - you helped me a lot - now I know where to go from now.

Regards Christian

[Smackey's dad]

The “dynamically allocated image” will create a small size file initially and will not occupy any space for unused virtual disk sectors. As data gets saved to the disk, it will grow dynamically. At the outset, the size of the disk will match the actual size of the file. However, when data on disk is deleted, the VDI file does not automatically shrink in size and retains the expanded size. To make it worse, new data written to the disk, does not reuse the existing “sectors”. Ext4 seeks consecutive unused sectors. This results in the file expanding to provide for the new sectors requested. This is an inherent behavior of the file system software (ext4) rather than VirtualBox. File systems were written for physical media. They allow the use of newer and contiguous sectors rather than attempting to reuse previously used/deleted sectors. This works well for physical media such that files are in contiguous sectors and newer sectors are used rather than over-use and wear out of disk sectors. However for virtualized disk, this translates to bloated disks occupying more space than what is in use. The approach to overcome this are:

• Size disks appropriately
• Grow disks as required with size growth
• Compact disks (using the modifyhd –compact command)

Below is the approach I use for sizing disks appropriately:
(1) Create a large dynamically disk - just like the way you have. No changes there.
(2) Partition the disk to it's full capacity - again no change from what you may have done
(3) Allocate the file system ONLY to the current size requirements.

For (3), in your case you will have to reduce the size of the existing filesystem. Use the resize2fs command to reduce the size of an unmounted partition. Later when you fill up the space, simple increase the size by an additional amount (say 10G) again using the resize2fs command. The good news is that for ext4 you do not need to unmount and can dynamically increase the filesystem size online.

Of course take backups before doing this. But the operation is quite straight forward. With this approach you will have the benefit of dynamic storage yet avoid the excessive growth.

Also to note you may need to compact what is already expanded before you do this as you may have already expanded to the outer sectors thus preventing you from reducing the filesystem size.

[mpack]

IMHO, retricting the logical size of the disk is not really a good idea. It will just lead to a congested and fragmented guest filesystem - and increasing the logical volume size in small increments will just keep it that way. Better to give the guest plenty of elbow room right at the start, and compact when needed.

p.s. "modifyhd --compact" does not actually compact the filesystem - you have to run zerofree first, and even then unpartitioned spaces will be omitted. This is why I recommended CloneVDI, which I designed to do the complete job in one pass.