[mirror_ubuntu-bionic-kernel.git] / drivers / block / drbd / Kconfig

# SPDX-License-Identifier: GPL-2.0
#
# DRBD device driver configuration
#

comment "DRBD disabled because PROC_FS or INET not selected"
	depends on PROC_FS='n' || INET='n'

config BLK_DEV_DRBD
	tristate "DRBD Distributed Replicated Block Device support"
	depends on PROC_FS && INET
	select LRU_CACHE
	select LIBCRC32C
	default n
	help

	  NOTE: In order to authenticate connections you have to select
	  CRYPTO_HMAC and a hash function as well.

	  DRBD is a shared-nothing, synchronously replicated block device. It
	  is designed to serve as a building block for high availability
	  clusters and in this context, is a "drop-in" replacement for shared
	  storage. Simplistically, you could see it as a network RAID 1.

	  Each minor device has a role, which can be 'primary' or 'secondary'.
	  On the node with the primary device the application is supposed to
	  run and to access the device (/dev/drbdX). Every write is sent to
	  the local 'lower level block device' and, across the network, to the
	  node with the device in 'secondary' state.  The secondary device
	  simply writes the data to its lower level block device.

	  DRBD can also be used in dual-Primary mode (device writable on both
	  nodes), which means it can exhibit shared disk semantics in a
	  shared-nothing cluster.  Needless to say, on top of dual-Primary
	  DRBD utilizing a cluster file system is necessary to maintain for
	  cache coherency.

	  For automatic failover you need a cluster manager (e.g. heartbeat).
	  See also: http://www.drbd.org/, http://www.linux-ha.org

	  If unsure, say N.

config DRBD_FAULT_INJECTION
	bool "DRBD fault injection"
	depends on BLK_DEV_DRBD
	help

	  Say Y here if you want to simulate IO errors, in order to test DRBD's
	  behavior.

	  The actual simulation of IO errors is done by writing 3 values to
	  /sys/module/drbd/parameters/

	  enable_faults: bitmask of...
	  1	meta data write
	  2               read
	  4	resync data write
	  8	            read
	  16	data write
	  32	data read
	  64	read ahead
	  128	kmalloc of bitmap
	  256	allocation of peer_requests
	  512	insert data corruption on receiving side

	  fault_devs: bitmask of minor numbers
	  fault_rate: frequency in percent

	  Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.
		echo 16 > /sys/module/drbd/parameters/enable_faults
		echo 1 > /sys/module/drbd/parameters/fault_devs
		echo 5 > /sys/module/drbd/parameters/fault_rate

	  If unsure, say N.
Commit	Line	Data
b2441318	1	# SPDX-License-Identifier: GPL-2.0
b411b363 PR	2	#
	3	# DRBD device driver configuration
	4	#
	5
d2ec180c LE	6	comment "DRBD disabled because PROC_FS or INET not selected"
d2ec180c LE	7	depends on PROC_FS='n' \|\| INET='n'
b411b363 PR	8
	9	config BLK_DEV_DRBD
	10	tristate "DRBD Distributed Replicated Block Device support"
d2ec180c	11	depends on PROC_FS && INET
b411b363	12	select LRU_CACHE
d2ec180c	13	select LIBCRC32C
b411b363 PR	14	default n
	15	help
	16
	17	NOTE: In order to authenticate connections you have to select
	18	CRYPTO_HMAC and a hash function as well.
	19
	20	DRBD is a shared-nothing, synchronously replicated block device. It
	21	is designed to serve as a building block for high availability
	22	clusters and in this context, is a "drop-in" replacement for shared
	23	storage. Simplistically, you could see it as a network RAID 1.
	24
	25	Each minor device has a role, which can be 'primary' or 'secondary'.
	26	On the node with the primary device the application is supposed to
	27	run and to access the device (/dev/drbdX). Every write is sent to
	28	the local 'lower level block device' and, across the network, to the
	29	node with the device in 'secondary' state. The secondary device
	30	simply writes the data to its lower level block device.
	31
	32	DRBD can also be used in dual-Primary mode (device writable on both
	33	nodes), which means it can exhibit shared disk semantics in a
	34	shared-nothing cluster. Needless to say, on top of dual-Primary
	35	DRBD utilizing a cluster file system is necessary to maintain for
	36	cache coherency.
	37
	38	For automatic failover you need a cluster manager (e.g. heartbeat).
	39	See also: http://www.drbd.org/, http://www.linux-ha.org
	40
	41	If unsure, say N.
	42
b411b363 PR	43	config DRBD_FAULT_INJECTION
	44	bool "DRBD fault injection"
	45	depends on BLK_DEV_DRBD
	46	help
	47
	48	Say Y here if you want to simulate IO errors, in order to test DRBD's
	49	behavior.
	50
	51	The actual simulation of IO errors is done by writing 3 values to
	52	/sys/module/drbd/parameters/
	53
	54	enable_faults: bitmask of...
	55	1 meta data write
	56	2 read
	57	4 resync data write
	58	8 read
	59	16 data write
	60	32 data read
	61	64 read ahead
	62	128 kmalloc of bitmap
d2ec180c LE	63	256 allocation of peer_requests
d2ec180c LE	64	512 insert data corruption on receiving side
b411b363 PR	65
	66	fault_devs: bitmask of minor numbers
	67	fault_rate: frequency in percent
	68
	69	Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.
	70	echo 16 > /sys/module/drbd/parameters/enable_faults
	71	echo 1 > /sys/module/drbd/parameters/fault_devs
	72	echo 5 > /sys/module/drbd/parameters/fault_rate
	73
	74	If unsure, say N.