I have a Domino cluster with two clustermates. All the dbs in the first node are also in the second, DAOS catalogs are synchronized, it seems that there are no replication issues, cluster always works fine.
On every clustermate there is a disk dedicated to DAOS: how you could explain that attachments on the first node take up much more disk space that those on the second one? Am I missing something obvious? I have not yet launched a listnlo MISSING…
Thanks.
Stefano
Subject: A few things to check on both machines
First DAOS Configuration Settings match for each Cluster Mate…
DAOS Settings
Store file attachments in DAOS: Enabled
Minimum size of object before Domino will store in DAOS: 64000 bytes
DAOS base path: g:\daos
Defer object deletion for: 14 days
Second thing to check is that DAOS is enabled on same set of databases on both Cluster Mates using Admin Client “DAOS State” column in Files Tab
Third thing to do is make sure a copy style compact has been done recently on all databases using Admin Client “Last Compact” column in Files Tab
Maybe force one more prune on both servers (tell daosmgr prune 14) - I’m just using 14 days as that’s what I have configured above for defer object deletion for:
If that still doesn’t do it you can do comparisons from Administration Client of “DAOS Size” column in Files Tab for each database
jpaganet@us.ibm.com
Subject: Good suggestions…more
What John said… I’d stick to a larger minimum participation size (1Mb is a good start) than his examples, but the rest is dead on.
plus…
-
Is everything DAOS-enabled? Double check that all files on both servers DAOS enabled (or not) as you expect them to be.
-
Storage format - DAOS gets the data after all NSF-level encoding/compression/encryption options have been applied, and considers the uniqueness based on that stream of bytes. Differences in encoding (MIME, native) and compression (none, huffman, lz1) will cause different NLO files to be created. Encrypted data (NSF-level, not DAOS encryption) can cause multiple unique NLO files to be created depending on the way they were created.
-
Mail routing - it’s possible for ‘transient’ objects to appear in the DAOS repository as a side effect of mail routing. These are ‘just passing through’ attachments that are stored for mail.box, and were deleted after being sent on to somewhere else. The DAOS deferred deletion interval will retain these until they are pruned.
-
IMAP/POP and MIME - If you have mail clients polling the server, MIME formats the messages for the client and stores them temporarily in an attachment in the user’s mailfile. These can end up being stored in DAOS, and can build up. Please see PPOR8XZLPN (included in 9.x and newer) and enable DAOS_AVOID_MIME=1 if this is the case