Dirty Region Logging is mentioned often in the VxVM manuals but poorly explained. For most people I've talked to they had a difficult time trying to get a grasp of what it is. The way I like to introduce DRL to new users is to ask them to think of DRL as journaling (like a journaling filesystem) for volumes. Now, in fact this isn't exactly correct, but it's a good starting point.
DRL is a fault recovery mechanism. When logging is enabled for a volume a bitmap is created representing the volume it's attached to. When a volume region is modified it's corresponding bit in the bitmap is marked dirty BEFORE the write is made to the volume. A region is a logical portion of the volume that is defined and used by DRL, which is considered more efficient than block-by-block logging. By default, a region is defined as 1024 sectors. After the write operation completes to the volume DRL doesn't remove the dirty bit. The bit isn't removed until it is the "least recently used". By default, the maximum number of dirty regions a system can have at one time is 2048. Therefore once 2048 regions are marked dirty the first region marked dirty will be cleared. If a region is to be marked dirty, but a dirty bit is already set the previous dirty bit is let stand, and the write is made. Note that DRL is only effective for mirrored volumes.
The big idea here is that should your system crash for one reason or another the system would normally have to sync all the mirrors in the volume before making the volume available, all because the system doesn't know what changed, so it has to check everything. However DRL provides a mechanism by which to know exactly what has changed, therefore speeding up the sync'ing process by only sync'ing the "dirty" regions. Handy huh?
Okey, here's the big remaining question most people have: "If data is written to all mirrors in parallel, and the system crashes in the middle of a write there the data in the region is still going to be mangled. How is DRL going to make sure the valid data is in place?" And the answer is that DRL isn't intended to protect the validity of your data, but rather that all the data is consistent. Let me explain a bit more.
Remember that a volume manager doesn't understand the data it contains, it's a bit bucket. The volume manager's whole purpose in life it to protect what you write to it, and make sure that it's available to you, NOT to verify that your data is what you intended it to be. Often this is forgotten. So, back to DRL, if the system crashes in the middle of a write, all the region the data was being written to may not be identical. In theory this wouldn't be a problem, but I/O slow downs, disk speeds, and other performance factors make parallel data writes happen at slightly different times. Therefore, each mirror may have different data in region that was being written. DRL simply makes sure that all the data in the dirty region is identical, regardless is the data is any good or not. If the regions where not identical across mirrors two reads to the same region of the volume could have different results. DRL at least makes sure that all the regions have the same data, by sync'ing the regions from the preferred plex. The data might be crap, but at least it's consistent crap!
To enable DRL for a volume you can simply use vxassist:
vxassist addlog <volumename> |
VxAssist will create a subdisk, mark it as a log disk, and then attach it to a plex. And that's it! A really simple process.
Note that log subdisks length corresponds to the length of the logged volume. The log subdisk should contain 1 sector for every 1G of volume. So if your log subdisk is 80 sectors long, and you decide to grow the volume to 120G your going to need to grow the DRL as well.
Also, logs can be mirrored simply by adding another log subdisk to the volume. But also know that you can only have 1 log subdisk per plex.
DRL can not be used on root volumes, including: rootvol, standvol, swapvol, and usr.