A number of Zimbra versions ago, Zimbra used to configure Amavis's temporary directory to run on a RAM disk. Since Amavis doesn't always clean up its temporary directory well, in some installations the RAM disk would fill up and Amavis would stop working. So, Zimbra changed the install scripts going forward by removing the code that set this up.
The Book of Postfix (No Starch Press) and many other Postfix docs point out that running Amavis's temp folder on a RAM disk is actually quite safe. When Postfix hands off an email to Amavis for processing, Amavis does not actually acknowledge receiving the email from Postfix until Amavis has finished processing the email and successfully reinjected it back into Postfix. As a result, you could pull the power plug on the server and not lose any email by running Amavis's temp directory on a RAM disk. (You might hose your server for other reasons there Sparky, but not from running Amavis's temp directory on a RAM disk.)
The key benefit to running Amavis's temp directory in a RAM disk is performance. Processing by clamav, spamassassin (and Razor, Pyzor, DSpam or whatever else an admin has hacked Zimbra's Amavis to use) is very disk intensive.
So, if you have a Zimbra server with a lot of RAM and a growing number of active users, mounting /opt/zimbra/amavisd/tmp on a RAM disk is a simple way to claw back disk idle times and some increased performance.
We've been watching /opt/zimbra/amavisd/tmp since 4.5.3, and have not noticed any "orphaned" Amavis temp files like we saw in the 4.0 series, so we are asking if in Zimbra's opinion if they are OK with us putting /opt/zimbra/amavisd/tmp back on a RAM disk--understanding of course that this may not be a fully supported installation.
To create a 200MB RAM disk, we would:
1. zmcontrol stop
2. rm -R /opt/zimbra/amavisd/tmp/
3. add the following line to /etc/fstab:
/dev/shm /opt/zimbra/amavisd/tmp tmpfs defaults,size=200m,mode=700,uid=1003,gid=1000 0 0
(Note that the uid and gid above are the user id and group id for the 'zimbra' user and group, respectively and will likely have different values on different installations.)