Transient attachments and DAOS
When DAOS is enabled on a mail server, it is possible to get a buildup of attachments in the DAOS repository from transient attachments as mail passes through mail.box. What options are there for addressing this buildup?
Assume there are three servers (A, B, C) and server B is a mail hub. As mail is routed from server A to server C, the router task transfers the document (and attachments) from the mail.box file on server A to the mail.box file on server B. If DAOS is enabled on the mail.box file on server B, the attachment may be stored in DAOS. The router will then transfer the document to the mail.box file on server C, and delete it from the mail.box file on server B. Typically this occurs fairly quickly, so the attachment will be created and subsequently deleted on server B after a very short time.
Since DAOS does not immediately delete attachments when the reference count goes to zero, this can cause a buildup of objects in the DAOS repository. The default is 30 days before unreferenced attachments are deleted. These are essentially transient attachments that are of little use on a server that is just an intermediary for the mail routing process.
Here are several ways to mitigate the problem:
|Significantly reduce the duration of the 'deferred deletion interval' in the DAOS settings||If the server is a mail hub, with few or no other DAOS-enabled NSF files on the server, there is little reason to keep the data in DAOS for very long if it is "just passing through" the hub server. Changing the deferred deletion interval to 1 or 2 days will greatly reduce the amount of buildup, while still allowing it to take advantage of the DAOS object copy optimization introduced in version 8.5.1|
|Slightly reduce the duration of the 'deferred deletion interval'||If the server participates in mail routing but it also has resident DAOS-enabled NSF files, changing the deferred deletion interval drastically may lead to attachment data that is not backed up. One reason for the deferred deletion interval is to ensure that all NLO files are covered by at least one backup cycle. If you are on a weekly backup schedule, you could reduce the interval to 8 days. That would ensure that all NLO files have the opportunity to be backed up.|
|Turn DAOS off for mail.box||For a hub server, this choice will eliminate the transient attachment buildup. It will also mean that the effectiveness of the DAOS object copy optimization will be greatly reduced. The optimization can only be realized if the destination is DAOS-enabled. In the above scenario, if the mail.box on server B was not enabled for DAOS, the trip from A to B could not take advantage of the optimization, but the trip from B to C could.
This approach is not recommended for mail servers that also have user mail files on them. Turning off DAOS in that situation will greatly reduce the efficiency of the attachment copy from the server's mail.box file to the destination mail files. The end result will be the same (attachments stored in DAOS referenced by multiple mail files) but the intermediate steps to get there will be much less efficient.
Note that all references to 'mail.box' also apply to 'mail1.box' and the other similarly numbered files if you have enabled multiple mail.box files on your server.
More support for:
Software version: 8.5, 220.127.116.11, 8.5.1, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 8.5.2, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 8.5.3, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 9.0, 9.0.1
Operating system(s): AIX, IBM i, Linux, Solaris, Windows, z/OS
Reference #: 1426551
Modified date: 01 April 2010