← Back to branch summary

~ubuntu-branches/ubuntu/trusty/drbd8/trusty

« back to all changes in this revision

Viewing changes to documentation/drbd.conf.5

  • Committer: Bazaar Package Importer
  • Author(s): Andres Rodriguez
  • Date: 2011-07-05 15:40:13 UTC
  • mfrom: (1.4.6 upstream)
  • Revision ID: james.westby@ubuntu.com-20110705154013-f9l32owj6mi9e1p0
Tags: 2:8.3.11-0ubuntu1
* New upstream release
* debian/patches/01_ubuntu_cn_idx.dpatch: Refreshed.

Show diffs side-by-side

added added

removed removed

Lines of Context:
documentation/drbd.conf.5
253
253
\fBafter\-sb\-1pri\fR,
254
254
\fBafter\-sb\-2pri\fR,
255
255
\fBdata\-integrity\-alg\fR,
256
 
\fBno\-tcp\-cork\fR
 
256
\fBno\-tcp\-cork\fR,
 
257
\fBon\-congestion\fR,
 
258
\fBcongestion\-fill\fR,
 
259
\fBcongestion\-extents\fR
257
260
.RE
258
261
.PP
259
262
\fBstartup\fR
309
312
\fBafter\-resync\-target\fR\&.
310
313
.sp
311
314
The interface is done via environment variables:
312
 
.PP .RS 4 \fBDRBD_RESOURCE\fR is the name of the resource \fBDRBD_MINOR\fR is the minor number of the DRBD device, in decimal\&. \fBDRBD_CONF\fR is the path to the primary configuration file; if you split your configuration into multiple files (e\&.g\&. in \fB/etc/drbd\&.conf\&.d/\fR), this will not be helpful\&. \fBDRBD_PEER_AF\fR, \fBDRBD_PEER_ADDRESS\fR, \fBDRBD_PEERS\fR are the address family (e\&.g\&. \fBipv6\fR), the peer\*(Aqs address and hostnames\&. .RE
 
315
.PP
 
316
\fBDRBD_RESOURCE\fR
 
317
.RS 4
 
318
is the name of the resource
 
319
.RE
 
320
.PP
 
321
\fBDRBD_MINOR\fR
 
322
.RS 4
 
323
is the minor number of the DRBD device, in decimal\&.
 
324
.RE
 
325
.PP
 
326
\fBDRBD_CONF\fR
 
327
.RS 4
 
328
is the path to the primary configuration file; if you split your configuration into multiple files (e\&.g\&. in
 
329
\fB/etc/drbd\&.conf\&.d/\fR), this will not be helpful\&.
 
330
.RE
 
331
.PP
 
332
\fBDRBD_PEER_AF\fR, \fBDRBD_PEER_ADDRESS\fR, \fBDRBD_PEERS\fR
 
333
.RS 4
 
334
are the address family (e\&.g\&.
 
335
\fBipv6\fR), the peer\*(Aqs address and hostnames\&.
 
336
.RE
 
337
.sp
 
338
 
313
339
\fBDRBD_PEER\fR
314
 
is deprecated\&.
 
340
(note the singular form) is deprecated, and superseeded by DRBD_PEERS\&.
315
341
.sp
316
342
Please note that not all of these might be set for all handlers, and that some values might not be useable for a
317
343
\fBfloating\fR
467
493
or
468
494
\fBdetach\&.\fR
469
495
.sp
470
 
\fBpass_on\fR: Report the io\-error to the upper layers\&. On Primary report it to the mounted file system\&. On Secondary ignore it\&.
 
496
\fBpass_on\fR: The node downgrades the disk status to inconsistent, marks the erroneous block as inconsistent in the bitmap and retries the IO on the remote node\&.
471
497
.sp
472
498
\fBcall\-local\-io\-error\fR: Call the handler script
473
499
\fBlocal\-io\-error\fR\&.
832
858
DRBD usually uses the TCP socket option TCP_CORK to hint to the network stack when it can expect more data, and when it should flush out what it has in its send queue\&. It turned out that there is at least one network stack that performs worse when one uses this hinting method\&. Therefore we introducted this option, which disables the setting and clearing of the TCP_CORK socket option by DRBD\&.
833
859
.RE
834
860
.PP
 
861
\fBon\-congestion \fR\fB\fIcongestion_policy\fR\fR, \fBcongestion\-fill \fR\fB\fIfill_threshold\fR\fR, \fBcongestion\-extents \fR\fB\fIactive_extents_threshold\fR\fR
 
862
.RS 4
 
863
By default DRBD blocks when the available TCP send queue becomes full\&. That means it will slow down the application that generates the write requests that cause DRBD to send more data down that TCP connection\&.
 
864
.sp
 
865
When DRBD is deployed with DRBD\-proxy it might be more desirable that DRBD goes into AHEAD/BEHIND mode shortly before the send queue becomes full\&. In AHEAD/BEHIND mode DRBD does no longer replicate data, but still keeps the connection open\&.
 
866
.sp
 
867
The advantage of the AHEAD/BEHIND mode is that the application is not slowed down, even if DRBD\-proxy\*(Aqs buffer is not sufficient to buffer all write requests\&. The downside is that the peer node falls behind, and that a resync will be necessary to bring it back into sync\&. During that resync the peer node will have an inconsistent disk\&.
 
868
.sp
 
869
Available
 
870
\fIcongestion_policy\fRs are
 
871
\fBblock\fR
 
872
and
 
873
\fBpull\-ahead\fR\&. The default is
 
874
\fBblock\fR\&.
 
875
\fIFill_threshold\fR
 
876
might be in the range of 0 to 10GiBytes\&. The default is 0 which disables the check\&.
 
877
\fIActive_extents_threshold\fR
 
878
has the same limits as
 
879
\fBal\-extents\fR\&.
 
880
.sp
 
881
The AHEAD/BEHIND mode and its settings are available since DRBD 8\&.3\&.10\&.
 
882
.RE
 
883
.PP
835
884
\fBwfc\-timeout \fR\fB\fItime\fR\fR
836
885
.RS 4
837
886
Wait for connection timeout\&.
939
988
will lower the required bandwidth in exchange for CPU cycles\&.
940
989
.RE
941
990
.PP
942
 
\fBc\-plan\-ahead \fR\fB\fIplan_time\fR\fR, \fBc\-fill\-target \fR\fB\fIfill_target\fR\fR, \fBc\-delay\-target \fR\fB\fIdelay_target\fR\fR, \fBc\-max\-rate \fR\fB\fImax_rate\fR\fR, \fBc\-min\-rate \fR\fB\fImin_rate\fR\fR
 
991
\fBc\-plan\-ahead \fR\fB\fIplan_time\fR\fR, \fBc\-fill\-target \fR\fB\fIfill_target\fR\fR, \fBc\-delay\-target \fR\fB\fIdelay_target\fR\fR, \fBc\-max\-rate \fR\fB\fImax_rate\fR\fR
943
992
.RS 4
944
993
The dynamic resync speed controller gets enabled with setting
945
994
\fIplan_time\fR
961
1010
\fIdelay_target\fR\&. 5 times RTT is a reasonable starting value\&.
962
1011
\fIMax_rate\fR
963
1012
should be set to the bandwidth available between the DRBD\-hosts and the machines hosting DRBD\-proxy, or to the available disk\-bandwidth\&.
964
 
\fIMin_rate\fR
965
 
is the lower bound for the controller\&. If you set it to zero, resync IO requests will always get out of the way of application IO requests\&.
966
1013
.sp
967
1014
The default value of
968
1015
\fIplan_time\fR
973
1020
has 1 (100ms) and 0\&.1 as default unit\&.
974
1021
\fIMax_rate\fR
975
1022
has 10240 (100MiB/s) and KiB/s as default unit\&.
 
1023
.sp
 
1024
The dynamic resync speed controller and its settings are available since DRBD 8\&.3\&.9\&.
 
1025
.RE
 
1026
.PP
 
1027
\fBc\-min\-rate \fR\fB\fImin_rate\fR\fR
 
1028
.RS 4
 
1029
A node that is primary and sync\-source has to schedule application IO requests and resync IO requests\&. The
 
1030
\fImin_rate\fR
 
1031
tells DRBD use only up to min_rate for resync IO and to dedicate all other available IO bandwidth to application requests\&.
 
1032
.sp
 
1033
Note: The value 0 has a special meaning\&. It disables the limitation of resync IO completely, which might slow down application IO considerably\&. Set it to a value of 1, if you prefer that resync IO never slows down application IO\&.
 
1034
.sp
 
1035
Note: Although the name might suggest that it is a lower bound for the dynamic resync speed controller, it is not\&. If the DRBD\-proxy buffer is full, the dynamic resync speed controller is free to lower the resync speed down to 0, completely independent of the
 
1036
\fBc\-min\-rate\fR
 
1037
setting\&.
 
1038
.sp
 
1039
 
976
1040
\fIMin_rate\fR
977
1041
has 4096 (4MiB/s) and KiB/s as default unit\&.
978
 
.sp
979
 
The dynamic resync speed controller and its settings are available since DRBD 8\&.3\&.9\&.
980
1042
.RE
981
1043
.PP
982
1044
\fBon\-no\-data\-accessible \fR\fB\fIond\-policy\fR\fR
1081
1143
\fBnetwork\fR
1082
1144
section\&.
1083
1145
.PP
1084
 
Both mechanisms might deliver false positives if the user of DRBD modifies the data which gets written to disk while the transfer goes on\&. Currently the swap code and ReiserFS are known to do so\&. In both cases this is not a problem, because when the initiator of the data transfer does this it already knows that that data block will not be part of an on disk data structure\&.
1085
 
.PP
1086
 
The most recent (2007) example of systematically corruption was an issue with the TCP offloading engine and the driver of a certain type of GBit NIC\&. The actual corruption happened on the DMA transfer from core memory to the card\&. Since the TCP checksum gets calculated on the card this type of corruption stays undetected as long as you do not use either the online
 
1146
Both mechanisms might deliver false positives if the user of DRBD modifies the data which gets written to disk while the transfer goes on\&. This may happen for swap, or for certain append while global sync, or truncate/rewrite workloads, and not necessarily poses a problem for the integrity of the data\&. Usually when the initiator of the data transfer does this, it already knows that that data block will not be part of an on disk data structure, or will be resubmitted with correct data soon enough\&.
 
1147
.PP
 
1148
The
 
1149
\fBdata\-integrity\-alg\fR
 
1150
causes the receiving side to log an error about "Digest integrity check FAILED: Ns +x\en", where N is the sector offset, and x is the size of the requst in bytes\&. It will then disconnect, and reconnect, thus causing a quick resync\&. If the sending side at the same time detected a modification, it warns about "Digest mismatch, buffer modified by upper layers during write: Ns +x\en", which shows that this was a false positive\&. The sending side may detect these buffer modifications immediately after the unmodified data has been copied to the tcp buffers, in which case the receiving side won\*(Aqt notice it\&.
 
1151
.PP
 
1152
The most recent (2007) example of systematic corruption was an issue with the TCP offloading engine and the driver of a certain type of GBit NIC\&. The actual corruption happened on the DMA transfer from core memory to the card\&. Since the TCP checksum gets calculated on the card, this type of corruption stays undetected as long as you do not use either the online
1087
1153
\fBverify\fR
1088
1154
or the
1089
1155
\fBdata\-integrity\-alg\fR\&.