Fragmentation and Domino
Chris Whisonant
Over at IdeaJam, someone posted an idea on certifying NTFS defragmentation utilities for Domino. Below is my comment there - I would love to see what some of you think about this. Also, here is an example of what I see time and again when looking at fragmentation on Domino systems:
I don't care what file system you use, if you are using Domino you will have fragmentation. Even the WAFL fs has a defrag utility, even though it may be less susceptible.
The "problem" with Domino databases is that right after you defrag the volume, the file system starts to fragment because you're adding to the databases and that data has to go somewhere. It cannot go into a contiguous block because there may not be block space available due to the defrag tool keeping all files contiguous when defragging. And this isn't necessarily a problem with Domino - it's more of an issue with the file system and how it allocates storage.
To deal with this and achieve good uptime, I had hoped that a copy-style compact would be a poor man's defrag. Initially, it would seem that this would work because a new copy of the database would be created. However, this is not so because Domino doesn't (or can't?) always allocate a contiguous block that will store the entire database. Besides, Domino creates the database and has to start allocating space for the individual documents. Even if Domino could allocate a contiguous block, it would still suffer from fragmentation when new documents are added. (note: I didn't put this at my Idea Jam comment, but I would note that other transactions on the system will likely start to allocate blocks where the copy-style compact would be placing the data, so this is why more fragmentation may occur).
If Domino could get around this and use a contiguous block, I would propose something like "load compact -c +10" so that you get 10% white space in the new copy. Then you could have some white space in which new documents can be created and not cause further fragmentation.
Taking Domino out of the equation, something that may actually be faster than a defrag is to move all of the databases (or at least the largest or most heavily fragmented) off of the disk onto another volume and then run a defrag on the remaining files on that drive. Then just move the data back and the file system should allocate contiguous blocks for the new data while it's creating them one at a time.
Any other thoughts?