The reason for my concern? We have been told that the DAOS store has lesser disk performance demands than say the Transaction Logs or the data directory, yet it appears that when a DAOS MGR RESYNC or similar operation is initiated, actually a very intensive audit of the DAOS area takes place. This is where the 40,000 file per directory comes in... Just doing an 'ls' or 'dir' of a very large directory like that takes a significant time, particularly when this area is stored on NFS or iSCSI disk. In the case of a NFS mounted DAOS directory (say on an enterprise-class NetApps file), that 40000 files per subcontainer is too much. When the DAOS MGR RESYNC starts, it enumerates the contents of all the subcontainers. Due to the nature of NFS this is an extremely intensive operation. For 1.2 million attachments in 30 subcontainers this takes quite some time on NFS (3 hours or so) and is a heavy hit on the NFS filer performance. During this time, the daos catalogue daos cat.nsf is "unavailable", and so mail routing cannot occur until directory enumeration is complete. This is only going to get worse as more attachments are added to the DAOS store. Whenever the DAOS is resync'd, mail cannot be routed until this initial phase is completed and it starts on the databases themselves. In my opinion, we would see much better performance on initial resync if file count per subcontainer can be restricted to 5000 files or less for situations such as NFS. So if there isn't a means of decreasing the files/directory ratio now, can one be created? Feedback number SMIE82TFFY created by Stuart McIntyre on 19.02.2010
SPR# VPRS7ZVTNM - If the DAOS storage path is moved under the regular Domino data hierarchy, it can cause DbDirMan to not detect that it is a DAOS subdirectory and so it will try to scan it while refreshing the cache of databases. When there are lots of files in DAOS, this can cause a performance drop while the scan is in progress. This fix will allow DbDirMan to identify and skip the DAOS data subdirectory when it has been moved into the Domino data hierarchy instead of away from it.