If you're having a serious problem with fragmentation then you may want to use something other than NTFS. For example, the NetApp WAFL file system pretty much avoids the fragmentation problem entirely.

We had a problem on ext3, which made the domino doing its maintainance tasks about 5 times longer (8h instead of 1,5 for a compact) than with a fresh filesystem... And the FS was not even half full :-(

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.

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?

ext2 seems to solve this problem, as it allocates space in a block bigger than the initial file. So a hopefully copy-style compact will solve our problem. Having somthing like your parameter or the idea with 'certain-size'-DBs seems to be good idea nevertheless...

The move around was just what we did (instead of defrag, we reformated the partition, as it was almost dominodata only :-)

(3) - You can sort of achieve this (over time) by doing a compact -S10 (and as long as people delete documents from their database)