Table of Contents
- 17.1. DRBD meta data
- 17.2. Generation Identifiers
- 17.3. The Activity Log
- 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.
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.
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”.
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”.
Cs is the data device size in sectors.
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: