Specifications

Lotus Redbooks Wiki – IBM Lotus Notes and Domino V8.5 Deployment Guide
71
Compacting and White Space
When COMPACT -b runs on a mail file, or indeed any DB; rather than decrease the size of the DB, this
Lotus recommended "purge" increases white space and decreases the percentage of the file used. Simply
put, compact -b reorders data in a database so that the data is consecutive. The utilization percentage goes
up while space is compacted within the NSF structure. The file size remains the same.
By defragmenting the DB, the white spaces become a single large "white space" and thus we now have
room for larger incoming items, mail, attachments, and so on. This new incoming "data" we can now
accommodate within the existing DB without having to "expand" the DB by adding additional new blocks to
the end. The DB will gradually again becomes more fragmented through use. As random records (notes) are
deleted creating smaller white space holes, the DB becomes increasingly fragmented. Consequently larger
incoming notes and files, attachments and so on, will no longer fit within any spaces inside the DB, and so
the DB must expand itself.
Thus frequent defragmentation is required to keep the white space in a usable, contiguous form as much as
possible.
Re-Using White Space
Because Notes reuses white space within a database before allocating additional storage, the rate of
perceived growth of any DB will slow down, and eventually stop, as the amount of white space created by
COMPACT -b approaches the actual storage required for new content delivered during the day or days
between compactions, and the more or less equal rate of unwanted mail item deletions! This can be called
"steady state".
Thus eventually all DBs will reach steady state, freeing and re-using their own white-space, and taking the
laborious task of managing and worrying about data growth away from the Administrator. Which is why we
recommend it.
Looking closer at the actual OS side of things:
Looking at the situation from an OS file system point of view, this also makes total sense. If we have to
expand a file, we have to onerously find free blocks on the disk, map and allocate them to our file, alter the
disk index tables (for example, FATs or Inodes), and finally move the file end pointer to the (now extended)
end of file block. This is quite an expensive operation, and when repeated multiple times (each time you
grow the file) we will start to add to the "dead weight" of non-useful operations you are asking the system to
perform.
Disk Fragmentation! A thing of the past?
Administrators tend to ignore disk fragmentation, but shouldn't. Yes disks are much faster, and can recover
blocks from anywhere on the surface much quicker these days, but if all the blocks for a file were kept
together, rather than randomly scattered, then seek and access times would decrease noticeably.
This is what COMPACT -b attempts to do by periodically using COMPACT -B or -C and making the OS run
all over the disk to find additional spare blocks.
Gradually, with continual truncation of white space and the subsequent inevitable re-allocation of new disk
blocks, the whole disk will become more and more fragmented, resulting in a gradual, almost imperceptible
loss of performance day by day, but over a longer period this will be significant, if hard to measure
comparatively. Until you do an OS level disk de-frag and then marvel at the improved performance.
But surely I will need more disk?