486c6fba90
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
74 lines
2.4 KiB
Plaintext
74 lines
2.4 KiB
Plaintext
# 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
|
|
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.
|