...

Sections in parentheses affect other parts of the composition. The contents of the common section apply to all resources. The disk section of a resource or resource section applies to all volumes of that resource, and the network section of the resource section applies to all connections of that resource. This eliminates the need to repeat the same option for each resource, connection or volume. You can override more specific options in the Resources, Connections, Volumes or Volumes section. The peer-device options are defined as resync-rate, c-plan-ahead, c-delay-target, c-fill-target, c-max-rate and c-min-rate, and all disks for backward compatibility. Sections can also be specified. They are inherited by all relevant links. If granted in the connection section, it is inherited by all volumes in that connection. The "peer-device-options" section begins with the "disk" keyword. The "peer-device-options" section begins with the "disk" keyword.

Sections

global

Define some global parameters. All parameters in this section are optional. Only one global section is allowed in the configuration.

...

You can specify an alias for the hostname. You can use the specified hostname-alias as hostname in the on section.(bsr 1.7.2 and later)

common

This section can contain each a disk, handlers, net, options, and startup section. All resources inherit the parameters in these sections as their default values.

...

Defines the time the init script waits for all peers to connect. This can be useful in combination with cluster managers who cannot manage bsr resources. When the cluster manager starts, the bsr resource is already running. Timeouts are specified in seconds. The default is 0, indicating an infinite timeout. See also degr-wfc-timeout parameter.

resource

resource name

Define a resource. Usually contains at least two on sections and at least one connection section.

...

Defines the unique node identifier for a node in the cluster. Node identifiers are used to identify individual nodes in the network protocol, and to assign bitmap slots to nodes in the metadata. Node identifiers can only be reasssigned in a cluster when the cluster is down. It is essential that the node identifiers in the configuration and in the device metadata are changed consistently on all hosts. To change the metadata, dump the current state with bsrmeta dump-md, adjust the bitmap slot assignment, and update the metadata with bsrmeta restore-md. The node-id parameter must be set. Its value ranges from 0 to 16; there There is no default value and to adjust the value you must do so while the resource is down.

options

svc-auto-up

Automatically start the resource when the bsr service starts. The default is yes.

...

Define the device name and minor number of a replicated block device. This is the device that applications are supposed to access; in most cases, the device is not used directly, but as a file system. This parameter is required and the standard device naming convention is assumed. In addition to this device, udev will create /dev/bsr/by-res/resource /volume and /dev/bsr/by-disk/lower-level-device symlinks to the device. To change the value, you must do so while the resource is down.

disk {[disk] | none}

Define the lower-level block device that bsr will use for storing the actual data. While the replicated bsr device is configured, the lower-level device must not be used directly. Even read-only access with tools like dumpe2fs(8) and similar is not allowed. The keyword none specifies that no lower-level block device is configured; this also overrides inheritance of the lower-level device. To change the value, you must do so while the resource is down.

meta-disk internal,

meta-disk device,

...

Define where the metadata of a replicated block device resides: it can be internal, meaning that the lower-level device contains both the data and the metadata, or on a separate device. When the index form of this parameter is used, multiple replicated devices can share the same metadata device, each using a separate index. Each index occupies 128 MiB of data, which corresponds to a replicated device size of at most 4 TiB with two cluster nodes. We recommend not to share metadata devices anymore, and to instead use the lvm volume manager for creating metadata devices as needed. When the index form of this parameter is not used, the size of the lower-level device determines the size of the metadata. The size needed is 36 KiB + (size of lower-level device) / 32K * (number of nodes - 1). If the metadata device is bigger than that, the extra space is not used. This parameter is required if a disk other than none is specified, and ignored if disk is set to none. A meta-disk parameter without a disk parameter is not allowed. To change the value, you must do so while the resource is down.

floating

floating [address-family] addr:port

...

The maximum effective value is 919 * (available on-disk activity log ring buffer area / 4kB -1), which is up to 6433 (including 25 GiB or more data) in the default 32KB ring buffer. It's a good idea to keep the size of the activity log within an amount where the backend storage and replication links can be resynchronized in about 5 minutes.

Changing the size of al-extents requires a stopping the resource down.

al-updates {yes | no}

With this parameter, the activity log can be turned off entirely (see the al-extents parameter). This will speed up writes because fewer meta-data writes will be necessary, but the entire device needs to be resynchronized opon recovery of a failed primary node. The default value for al-updates is yes.

...

Online verification (bsradm verify) computes and compares checksums of disk blocks (i.e., hash values) in order to detect if they differ. The verify-alg parameter determines which algorithm to use for these checksums. It must be set to one of the secure hash algorithms supported by the kernel before online verify can be used; see the shash algorithms listed in /proc/crypto. We recommend to schedule online verifications regularly during low-load periods, for example once a month. Also see the notes on data integrity below.

stacked-on-top-of

Used instead of an on section for configuring a stacked resource with three to four nodes. Stacking is deprecated in bsr, we recommend using a 1:N replication configuration.

...