...
피어 장치. 리소스:연결이름/볼륨번호(resource:connection-name/volume)로 지정합니다. 리소스, 장치, 연결만 지정하면 해당 문맥의 모든 피어 장치에 대해 명령을 반복합니다.
이중 대시 다음의 모든 옵션은 지정된대로 하위 수준 유틸리티로 전달됩니다. 또한, bsradm은 bsrsetup의 대부분의 옵션을 이해하며 대부분 옵션을 알고 있으며 모든 이중 대시 옵션 또는 이중 대시 없이도 없는 옵션을 지정된 하위 수준 유틸리티에 전달합니다.
OPTIONS
-d, --dry-run
...
bsrsetup disk-options minor
The attach command attaches a lower-level device to an existing replicated device. The disk-options command changes the disk options of an attached lower-level device. In either case, the replicated device must have been created with bsrsetup new-minor.
Both commands refer to the replicated device by its minor number. lower_dev is the name of the lower-level device. meta_data_dev is the name of the device containing the metadata, and may be the same as lower_dev. meta_data_index is either a numeric metadata index, or the keyword internal for internal metadata, or the keyword flexible for variable-size external metadata. Available optionsattach 명령은 하위 수준의 장치를 기존 복제 장치에 연결합니다. disk-options 명령은 연결된 하위 장치의 디스크 옵션을 변경합니다. 두 경우 모두 bbssetup new-minor를 사용하여 복제 된 장치를 만들어야 합니다.
두 명령 모두 복제장치의 minor 번호로 지정합니다. lower_dev는 하위 장치의 이름입니다. meta_data_dev는 메타 데이터를 포함하는 장치의 이름이며, lower_dev와 동일 할 수 있습니다. meta_data_index는 인덱스 메타 데이터의 번호이거나 내부 메타 데이터의 경우 internal 키워드 또는 가변 크기의 외부 메타 데이터의 경우 flexible 키워드 입니다. 사용 가능한 옵션은 다음과 같습니다:
--al-extents extents
bsr automatically maintains a "hot" or "active" disk area likely to be written to again soon based on the recent write activity. The "active" disk area can be written to immediately, while "inactive" disk areas must be "activated" first, which requires a meta-data write. We also refer to this active disk area as the "activity log". The activity log saves meta-data writes, but the whole log must be resynced upon recovery of a failed node. The size of the activity log is a major factor of how long a resync will take and how fast a replicated disk will become consistent after a crash. The activity log consists of a number of 4-Megabyte segments; the al-extents parameter determines how many of those segments can be active at the same time. The default value for al-extents is 1237, with a minimum of 7 and a maximum of 65536. Note that the effective maximum may be smaller, depending on how you created the device meta data, see also bsrmeta(8) The effective maximum is 919 * (available on-disk activity-log ring-buffer area/4kB -1), the default 32kB ring-buffer effects a maximum of 6433 (covers more than 25 GiB of data) We recommend to keep this well within the amount your backend storage and replication link are able to resync inside of about 5 minutes.
--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.
--disk-barrier, --disk-flushes, --disk-drain bsr has three methods of handling the ordering of dependent write requests:
disk-barrier
Use disk barriers to make sure that requests are written to disk in the right order. Barriers ensure that all requests submitted before a barrier make it to the disk before any requests submitted after the barrier. This is implemented using 'tagged command queuing' on SCSI devices and 'native command queuing' on SATA devices. Only some devices and device stacks support this method. The device mapper (LVM) only supports barriers in some configurations. Note that on systems which do not support disk barriers, enabling this option can lead to data loss or corruption. Until bsr 8.4.1, disk-barrier was turned on if the I/O stack below bsr did support barriers. Kernels since linux-2.6.36 (or 2.6.32 RHEL6) no longer allow to detect if barriers are supported. Since bsr-8.4.2, this option is off by default and needs to be enabled explicitly.
disk-flushes
Use disk flushes between dependent write requests, also referred to as 'force unit access' by drive vendors. This forces all data to disk. This option is enabled by default.
disk-drain
Wait for the request queue to "drain" (that is, wait for the requests to finish) before submitting a dependent write request. This method requires that requests are stable on disk when they finish. Before bsr 8.0.9, this was the only method implemented. This option is enabled by default. Do not disable in production environments.
From these three methods, bsr will use the first that is enabled and supported by the backing storage device. If all three of these options are turned off, bsr will submit write requests without bothering about dependencies. Depending on the I/O stack, write requests can be reordered, and they can be submitted in a different order on different cluster nodes. This can result in data loss or corruption. Therefore, turning off all three methods of controlling write ordering is strongly discouraged.
...