If the backing block devices can be grown while in operation (online), it is also possible to increase the size of a DRBD device based on these devices during operation. To do so, two criteria must be fulfilled:
Connected
connection state.
Having grown the backing block devices on both nodes, ensure that only one node is in primary state. Then enter on one node:
# drbdadm resize <resource>
This triggers a synchronization of the new section. The synchronization is done from the primary node to the secondary node.
If the space you’re adding is clean, you can skip syncing the additional space by using the --assume-clean option.
# drbdadm -- --assume-clean resize <resource>
When the backing block devices on both nodes are grown while DRBD is inactive, and the DRBD resource is using external meta data, then the new size is recognized automatically. No administrative intervention is necessary. The DRBD device will have the new size after the next activation of DRBD on both nodes and a successful establishment of a network connection.
If however the DRBD resource is configured to use internal meta data, then this meta data must be moved to the end of the grown device before the new size becomes available. To do so, complete the following steps:
![]() | Warning |
---|---|
This is an advanced procedure. Use at your own discretion. |
# drbdadm down <resource>
# drbdadm dump-md <resource> > /tmp/metadata
You must do this on both nodes, using a separate dump file for every node. Do not dump the meta data on one node, and simply copy the dump file to the peer. This will not work.
la-size-sect
) in the file
/tmp/metadata
accordingly, on both nodes. Remember that
la-size-sect
must be specified in sectors.
# drbdadm create-md <resource>
# drbdmeta_cmd=$(drbdadm -d dump-md <resource>) # ${drbdmeta_cmd/dump-md/restore-md} /tmp/metadata Valid meta-data in place, overwrite? [need to type 'yes' to confirm] yes Successfully restored meta data
![]() | Note |
---|---|
This example uses |
# drbdadm up <resource>
# drbdadm primary <resource>
![]() | Warning |
---|---|
Online shrinking is only supported with external metadata. |
Before shrinking a DRBD device, you must shrink the layers above DRBD, i.e. usually the file system. Since DRBD cannot ask the file system how much space it actually uses, you have to be careful in order not to cause data loss.
![]() | Note |
---|---|
Whether or not the filesystem can be shrunk on-line depends on the filesystem being used. Most filesystems do not support on-line shrinking. XFS does not support shrinking at all. |
To shrink DRBD on-line, issue the following command after you have shrunk the file system residing on top of it:
# drbdadm resize --size=<new-size> <resource>
You may use the usual multiplier suffixes for <new-size> (K, M, G etc.). After you have shrunk DRBD, you may also shrink the containing block device (if it supports shrinking).
If you were to shrink a backing block device while DRBD is inactive, DRBD would refuse to attach to this block device during the next attach attempt, since it is now too small (in case external meta data is used), or it would be unable to find its meta data (in case internal meta data is used). To work around these issues, use this procedure (if you cannot use on-line shrinking):
![]() | Warning |
---|---|
This is an advanced procedure. Use at your own discretion. |
# drbdadm down <resource>
# drbdadm dump-md <resource> > +/tmp/metadata+
You must do this on both nodes, using a separate dump file for every node. Do not dump the meta data on one node, and simply copy the dump file to the peer. This will not work.
la-size-sect
) in the file
/tmp/metadata
accordingly, on both nodes. Remember that
la-size-sect
must be specified in sectors.
# drbdadm create-md <resource>
# drbdmeta_cmd=$(drbdadm -d dump-md <resource>) # ${drbdmeta_cmd/dump-md/restore-md} /tmp/metadata Valid meta-data in place, overwrite? [need to type 'yes' to confirm] yes Successfully restored meta data
![]() | Note |
---|---|
This example uses |
# drbdadm up <resource>