Journaling vs. scoreboarding
Rick Cook
When you backup your data files from your server, or from a workstation, it's important that you know the backup is accurate. How do you know that? Well. The backup system provider has to give you that capability, and there are two ways that these providers do it. This tip discusses the common approaches, journaling and scoreboarding, and the advantages and disadvantages of each. It's good-to-know info when you consider new equipment and/or upgrades.
Got a backup tip of your own? Why not send it in? We'll grant you instant fame by posting it on our Web site, and we'll enter you in our tips contest for some neat prizes.
The most common method of providing 'fail-safe' replication of data between two systems is some form of journaling where the system software keeps a running list of storage "writes" in a special log file called a journal. Journaling allows quickly restoring the state of system in the event of a crash or an interruption of the connection between the systems since the software can simply update the changed segments of the disk from the journal rather than having to check every sector on the disk to see if information was changed during the crash or interruption.
An alternate technique for data replication is scoreboarding. Rather than keep a list of all the writes to the disk, the system simply maintains a list of changed sectors. To resynchronize the data, the sectors in the scoreboard are rewritten. This is the method Sun uses (www.sun.com) in its StorEdge Network Data Replicator software.
Scoreboarding has one major advantage and one big disadvantage compared to journaling when it comes to synchronizing data. Because the scoreboard only keeps a list of changed sectors, rather than trying to log every write, it takes less space and avoids the problem of overflowing the journal partition if the interruption goes on for some time. If the same sector is rewritten one, ten or a hundred times during the interruption, as often happens with something like a transactional database, it only produces one entry in the scoreboard. This is important because overflowing the journal usually brings the whole system down, or at best requires a resychronization of all sectors of storage to make sure the data is correctly replicated.
The disadvantage flows from the same feature. Unlike a journal, a scoreboard does not keep a history list of the changes, only a list of the sectors that have changed. That means a scoreboard resychronization must run to completion to assure that the data at the replicated system is correct. A properly designed journaling system can be updated to any point in the outage.
Sun Microsystems discusses journaling and scoreboarding in its white paper on its data replication system at: www.sun.com/storage/white-papers/sndr.html.
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years he has been a freelance writer specializing in storage and other computer issues.
Did you like this tip? Whether you did or not, why not let us know. Drop us an e-mail and sound off.
