This guide describes DRBD version 8.4 and above. For 8.3 please look here.


Chapter 17. DRBD Internals

Table of Contents

17.1. DRBD meta data
17.1.1. Internal meta data
17.1.2. External meta data
17.1.3. Estimating meta data size
17.2. Generation Identifiers
17.2.1. Data generations
17.2.2. The generation identifier tuple
17.2.3. How generation identifiers change
17.2.4. How DRBD uses generation identifiers
17.3. The Activity Log
17.3.1. Purpose
17.3.2. Active extents
17.3.3. Selecting a suitable Activity Log size
17.4. The quick-sync bitmap
17.5. The peer fencing interface

This chapter gives some background information about some of DRBD’s internal algorithms and structures. It is intended for interested users wishing to gain a certain degree of background knowledge about DRBD. It does not dive into DRBD’s inner workings deep enough to be a reference for DRBD developers. For that purpose, please refer to the papers listed in Section 18.5, “Publications”, and of course to the comments in the DRBD source code.

17.1. DRBD meta data

DRBD stores various pieces of information about the data it keeps in a dedicated area. This metadata includes:

This metadata may be stored internally and externally. Which method is used is configurable on a per-resource basis.

17.1.1. Internal meta data

Configuring a resource to use internal meta data means that DRBD stores its meta data on the same physical lower-level device as the actual production data. It does so by setting aside an area at the end of the device for the specific purpose of storing metadata.

Advantage. Since the meta data are inextricably linked with the actual data, no special action is required from the administrator in case of a hard disk failure. The meta data are lost together with the actual data and are also restored together.

Disadvantage. In case of the lower-level device being a single physical hard disk (as opposed to a RAID set), internal meta data may negatively affect write throughput. The performance of write requests by the application may trigger an update of the meta data in DRBD. If the meta data are stored on the same magnetic disk of a hard disk, the write operation may result in two additional movements of the write/read head of the hard disk.

[Caution]Caution

If you are planning to use internal meta data in conjunction with an existing lower-level device that already has data which you wish to preserve, you must account for the space required by DRBD’s meta data.

Otherwise, upon DRBD resource creation, the newly created metadata would overwrite data at the end of the lower-level device, potentially destroying existing files in the process. To avoid that, you must do one of the following things:

  • Enlarge your lower-level device. This is possible with any logical volume management facility (such as LVM) as long as you have free space available in the corresponding volume groupIt may also be supported by hardware storage solutions.
  • Shrink your existing file system on your lower-level device. This may or may not be supported by your file system.
  • If neither of the two are possible, use external meta data instead.

To estimate the amount by which you must enlarge your lower-level device our shrink your file system, see Section 17.1.3, “Estimating meta data size”.

17.1.2. External meta data

External meta data is simply stored on a separate, dedicated block device distinct from that which holds your production data.

Advantage. For some write operations, using external meta data produces a somewhat improved latency behavior.

Disadvantage. Meta data are not inextricably linked with the actual production data. This means that manual intervention is required in the case of a hardware failure destroying just the production data (but not DRBD meta data), to effect a full data sync from the surviving node onto the subsequently replaced disk.

Use of external meta data is also the only viable option if all of the following apply:

  • You are using DRBD to duplicate an existing device that already contains data you wish to preserve, and
  • that existing device does not support enlargement, and
  • the existing file system on the device does not support shrinking.

To estimate the required size of the block device dedicated to hold your device meta data, see Section 17.1.3, “Estimating meta data size”.

17.1.3. Estimating meta data size

You may calculate the exact space requirements for DRBD’s meta data using the following formula:

Figure 17.1. Calculating DRBD meta data size (exactly)

metadata-size-exact

Cs is the data device size in sectors.

[Note]Note

You may retrieve the device size by issuing blockdev --getsz <device>.

The result, Ms, is also expressed in sectors. To convert to MB, divide by 2048 (for a 512-byte sector size, which is the default on all Linux platforms except s390).

In practice, you may use a reasonably good approximation, given below. Note that in this formula, the unit is megabytes, not sectors:

Figure 17.2. Estimating DRBD meta data size (approximately)

metadata-size-approx


This guide describes DRBD version 8.4 and above. For 8.3 please look here.