DAOS... Problem Solved
Tags: 
****This is the archive of my old blog, feel free to find this post on the new blog, please update your bookmarks****
I have been running the DAOS estimator for a while on my production servers, a lengthy process when your mail file has 6000+ mail files, but hey it is worth it when you look at a potential to save a couple of Terabyte.... yes you read that correctly saving a couple of Terabytes by enabling DAOS.
We have a quasi production server in other words it is my mail server and gets upgraded rather frequently (it is currently running 8.5 IF5, but with this issue behind us is likely to be running an 8.5.1 build shortly).
When attempting to set up DAOS on the server we ran in to the following error in the log
The database /lotus/domino/data/mail/xxxxxxxxx.TMP was unable to write to file /DAOS/0001/F0CEB8D561FA1F89852575F20069C85F47F0CEB8D561FA1P.nlo: File cannot be created
We checked known issues, checked with some folks who had a little more DAOS experience, and with IBM... no one had seen this issue. Interestingly enough if we manually created the 0001 directory DAOS would then enable just fine and create all the .NLO files, an easy solution though it left us wondering what would happen when the 0001 directory had 1000 objects and the 0002 directory had to be created.
First the solution, then the suspected cause.
1. Disable DAOS for all mail files (l compact mail\xxxx.nsf -c -daos off)
2. Shut down Domino
3. Remove all DAOS directories
4. Remofe daoscat.nsf and daos.cfg from the Notes Data directory
5. Restart Domino
6. Enable DAOS for a mail file to test (l compact mail\xxxx.nsf -c -daos on)
The suspected problem
This particular server is running on AIX, we suspect that when DAOS was first enabled the UNIX ID which owned the server did not have permission to create files in the DAOS file system (we had a dedicated file system created for DAOS did not put in under the Notes Data directory), however the DAOS Catalog believed the 0001 directory had been created even though it had not, so even after the permission issues were resolved DAOS would not enable properly for us until we followed the process detailed above).
So a word to the wise when creating you DAOS file systems double check those permission's before enabling DAOS. We are still working with IBM to create an SPR to give some better error messages when DAOS fails to create a directory or file.
Attachment consolidation (DAOS) -- Troubleshooting
DAOS Manager Tell commands
****Comments are closed here, got something to say? find this post on the new blog, where your comment is welcome****




-

Comments
Excellent finding Mitch !!!
Posted by ShrinivasS @ 08:21:35 AM on 07/14/2009 | - Website - |
In our case, I have a feeling the new 2048-bit key may have something to do with it - a known issue that's apparently to be fixed in 8.5 FP1...
Thanks again!
Posted by Sean Ramsay @ 08:07:54 PM on 07/16/2009 | - Website - |
Yes there was an issue in 8.5, in FP1 it is fixed
SPR# DROO7N9JC5 - "unable to write to the file" error seen in DAOS when server is using a 2048 bit Public Key (Technote #1365902
Posted by Jasza @ 09:17:29 AM on 10/01/2009 | - Website - |