Page Comparison

...

bsr implements a block device that replicates data from the local node to all other nodes in the cluster. Here, the actual data and related metadata are stored individually (usually in the case of external metadata) on the “generic” block device volume of each cluster node. Replication block devices must be named by default in /dev/bsr<minor> format or directly as a symbolic link (letter) to the device. One or more devices per resource are grouped and each device is replicated in parallel. The device inside the resource is defined as a volume, and resources can be duplicated between two or more cluster nodes. Cluster node-to-node connections are point-to-point links and use the TCP protocol. bsr consists of the basic components bsradm, which understands and processes configuration files, and the low-level components bsrsetup, bsrmeta, and bsrcon. The basic bsr configuration consists of /etc/bsr.conf and any additional files it contains (typically global_common.conf and all * .res files in the /etc path). Usually each resource is in etc/bsr.d/. It is useful to define separate * .res files in the path. The configuration file is designed so that each cluster node contains the same copy of the entire cluster configuration. However, sometimes it may be necessary to have the contents of different configuration files for each node, so this is not absolute.

resource r0 {
        net {
               protocol C;
        }
       disk {
              resync-rate 10M;
              c-plan-ahead 0;
       }
       on alice {
              volume 0 {
                       	device e minor 2;
						disk e;
						meta-disk f;
              }
             address 10.1.1.31:7789;
      }
      on bob {
            volume 0 {
                     disk e;
                     meta-disk f;
            }
           address 10.1.1.32:7789;
      }
}

This example defines the volume of letter e as the resource r0 containing a single replication device. This resource replicates between IPv4 addresses 10.1.1.31 and 10.1.1.32 and hosts alice and bob with node identifiers 0 and 1, respectively. The actual data is volume e, and the metadata is stored in volume f. Protocol C is used for connections between hosts.

...

The sections described below are defined. Indicates that the indented section is a subsection.

common
   [disk]
   [handlers]
   [net]
   [options]
   [startup]
global
resource
   connection
      path
      net
   connection-mesh
      net
   [disk]
   floating
   handlers
   [net]
   on
      volume
         disk
         [disk]
   options
 

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 maximum number of in-process (inflight) write I/O requests that can be allowed on the resource. The default value is 100000.

accelbuf-size size

Buffer size to improve local write performance in asynchronous replication. The default value is 10MB. accelbuf can quickly complete I/O by allocating one buffer and copying data from the generated write buffer space before copying it to the transmit buffer. (Supported after bsr 1.7)

max-accelbuf-blk-size size

The target I/O block size of the accelbuf buffer. The default value is 4KB, and accelbuf is applied only for write I/Os of 4KB or less. (Supported after bsr 1.7)

startup

The parameters in this section define the behavior of bsr at system startup time, in the bsr init script. They have no effect once the system is up and running.

...