Get news? 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | 1997 | About | Contact Want to help?

Linux-Kongress 2002
9th International Linux System Technology Conference
September 4-6, 2002 in Cologne, Germany

Home | Events | Program | Abstracts | Tutorials | BoFs | Fees | Exhibition | Location | Accommodations | Keysigning Party | Sponsors | Supporters | Reports and Photos | Papers and Slides | Call for Papers

See the list of all papers
Author Philipp Reisner
Title DRBD - Distributed Replicated Block Device
Postscript: (80546 Bytes)


High availability is a hot topic for service companies which offer their services via electronic networks. As Linux is in a position to gain a market share in newly build systems, there is a lot of interest in HA solutions for Linux based systems.

Quite a number of conventional HA solutions are brought to Linux these days and most of them are based on a shared storage device.

DRBD, however, is a more Linux-like approach to the field. As Linux brought PC hardware into the server market, DRBD brings HA clustering to the PC hardware. High availability in storage is realized by replicating the storage via off-the-shelf networking equipment to a second machine.

Since prices for gigabit ethernet hardware have declined and since 10 GB ethernet has become the standard, currently available off-the-shelf hardware offers the required performance.

Basic problems and algorithms

In this abstract only the areas of interest are mentioned, the complete algorithms are described in the final paper:

In order to achieve shared-disk like semantics over a networking protocol, DRBD has to guarantee not to violate write-ordering constraints imposed by upper software layers like journaling-file-systems.

In the event of a cluster restart, the nodes have to find the node with the up-to-date data (or the fact that all nodes are up-to-date).

Background resynchronization in case of a node joining a degraded cluster.

New requirements in DRBD 0.7

Quicker resynchronization. If no bitmap of out-of-date blocks is available, use hash values of blocks to speed up resynchronization.

In embedded applications and unmonitored installations, the remaining node must be able to continue to offer the service if a node is permanently damaged.

Decoupling of resynchronization from the node's role-assignment. Real-world use shows that this is often required and eases the interaction between DRBD and the cluster manager. This of course requires that DRBD offers a consistent view of the data even if the node's backing storage is the target of a resynchronization process.

Shared disk mode for use with openGFS. Although the block operation will support active/active configuration, it will turn out if it is usable without a common view of the cluster membership.


DRBD 0.6 proved its applicability for a number of purposes, mainly deployments in data-centers. Its replication performance was sufficient, but resynchronization was too slow. DRBD 0.7 will be applicable in embedded environments as well and will increase the possible storage size by speeding up resynchronization.

About the Author

Graduation from the Vienna University of Technology in computer science in 2000.

Since November 2001 MD at LINBIT, a provider of professional Linux services with a focus on high availability clustering.

Apart from DRBD, author of mergemem (a modification of Linux's memory management system)

Comments or Questions? Mail to Last change: 2005-09-17