Table of Contents
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.
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.
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 |
---|---|
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:
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”.
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:
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”.
You may calculate the exact space requirements for DRBD’s meta data using the following formula:
Cs is the data device size in sectors.
![]() | Note |
---|---|
You may retrieve the device size by issuing |
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: