You might like to take a look at this post.
Hi Bill, thanks - yes that is what we find, disk reported as 80GB but occupying a far fewer MBs. The issue is when you attempt to move or backup then you are shifting 80GB not the X MBs which is a fair overhead on data moves and storage. Question is why does it misreport the file size to the OS and create the problem?
Thanks for the link. When I ran du -c -h data.mdb, my db size is actually less than I thought -- 3.3 MB. But like kevindods said, any file operations require 80GB rather than 3.3MB. This is a big problem for backups. Plus, I just updated to 8.0.1 to facilitate a migration to a VM off of actual hardware. For a 3.3MB data file, there's really no need to create a massive virtual disk.
upgrade from 7.x to 8.0 this problem did not happen. From 8.0 to 8.01 is when the problem occured. Acording to this link OpenLDAP Tuning Keys 8.0 - Zimbra :: Wiki this should on happen from 7.x to 8.0
Well I am in the middle of an rsync and it certainly seems to be taking 80GB worth of time copying at the moment - the first copy run it sat at the data.mdb for a lot longer than say 80MB would! I will check it and see again but I am still not sure why it needs to allocate the 80GB? Other people are seeing backup failures too with - I did an rsync for the 7.2 install before the upgrade last night and it was much faster.
It was the rsync AND my backup software that alerted me to the 80GB problem. This is not merely speculation.I'll bet it takes a lot less time than you'd think an 80GB would be for copying.
Just ran a copy for the file when the actual size was 7MB - after 60s I decided it probably was copying the full 80GB - checking the du -c -h test-data.mdb file size was 7MB but it was no where near finished copying - 7MB/min is not the disk speed!
just to note that was time cp /opt/zimbra/data/ldap/mdb/db/data.mdb test-data.mdbRunning on Ubuntu, Ext4 on RAID10 15K drives - 8 cores 16GB RAMHouston - we have problem... as they probably didnt say!Bill: Where can we take this next?