Since this http://www.zimbra.com/forums/adminis...g-86gig-6.html thread is closed, I thought I'd post an update to clarify in hopes I'd help folks that rather not slog through many threads and posts.
Thank you to winepress and quanah for there help in understanding the situation. I'd like to summerize here their
updated procedure (8.0.2 and later) to shrink /opt/zimbra/data/ldap/mdb/db
Originally Posted by winepress
That's it, the commands winepress originally had after those two commands were to get around odd behavior in ldap/mdb in early Zimbra 8 (prior to 8.0.2).
# update database size
zmlocalconfig -e ldap_db_maxsize=67108864
# update log size
zmlocalconfig -e ldap_accesslog_maxsize=536870912
You might do such a crazy thing as shrink this file if you are in my situation:
(if you are totally small time like me)
1. You have very few users (I have less than 30).
2. You and your users make very little use of LDAP.
3. The size of the real data in the sparse file is very small. "du -ch" reports 1.5MB after several months of running.
4. You are migrating to a new filesystem... right sized in a VM, /opt is 60GB.
I understand an 80GB sparse file was "by design." I hope mdb gives HUGE performance increases because the amount of confusion and pain by small timers (that aren't throwing 1TB+ at this) is considerable. Not knowing that there were any sparse files, my rsync command (on a cold zimbra) filled up my destination FS. It took quite a bit of time to track down what was going on. (My first thoughts were large/odd block sizes of destination FS with many files... and then rsync getting confused and some how recursing following symlinks.)
I hope this helps someone not waste as much time as I have.