Signed-off-by: Thomas Schoebel-Theuer <[email protected]> --- drivers/staging/mars/Kconfig | 266 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 266 insertions(+) create mode 100644 drivers/staging/mars/Kconfig
diff --git a/drivers/staging/mars/Kconfig b/drivers/staging/mars/Kconfig new file mode 100644 index 0000000..836185e --- /dev/null +++ b/drivers/staging/mars/Kconfig @@ -0,0 +1,266 @@ +# +# MARS configuration +# + +config MARS + tristate "storage system MARS (EXPERIMENTAL)" + depends on BLOCK && PROC_SYSCTL && HIGH_RES_TIMERS && !DEBUG_SLAB && !DEBUG_SG + default n + ---help--- + MARS is a long-distance replication of generic block devices. + It works asynchronously and tolerates network bottlenecks. + Please read the full documentation at + https://github.com/schoebel/mars/blob/master/docu/mars-manual.pdf?raw=true + Always compile MARS as a module! + +config MARS_CHECKS + bool "enable simple runtime checks in MARS" + depends on MARS + default y + ---help--- + These checks should be rather lightweight. Use them + for beta testing and for production systems where + safety is more important than performance. + In case of bugs in the reference counting, an automatic repair + is attempted, which lowers the risk of memory corruptions. + Disable only if you need the absolutely last grain of + performance. + If unsure, say Y here. + +config MARS_DEBUG + bool "enable full runtime checks and some tracing in MARS" + depends on MARS + default n + ---help--- + Some of these checks and some additional error tracing may + consume noticeable amounts of memory. However, this is extremely + valuable for finding bugs, even in production systems. + + OFF for production systems. ON for testing! + + If you encounter bugs in production systems, you + may / should use this also in production if you carefully + monitor your systems. + +config MARS_DEBUG_MEM + bool "debug memory operations" + depends on MARS_DEBUG + default n + ---help--- + This adds considerable space and time overhead, but catches + many errors (including some that are not caught by kmemleak). + + OFF for production systems. ON for testing! + Use only for development and thorough testing! + +config MARS_DEBUG_MEM_STRONG + bool "intensified debugging of memory operations" + depends on MARS_DEBUG_MEM + default y + ---help--- + Trace all block allocations, find more errors. + Adds some overhead. + + Use for debugging of new bricks or for intensified + regression testing. + +config MARS_DEBUG_ORDER0 + bool "also debug order0 operations" + depends on MARS_DEBUG_MEM + default n + ---help--- + Turn even order 0 allocations into order 1 ones and provoke + heavy memory fragmentation problems from the buddy allocator, + but catch some additional memory problems. + Use only if you know what you are doing! + Normally OFF. + +config MARS_DEFAULT_PORT + int "port number where MARS is listening" + depends on MARS + default 7777 + ---help--- + Best practice is to uniformly use the same port number + in a cluster. Therefore, this is a compiletime constant. + You may override this at insmod time via the mars_port= parameter. + +config MARS_NET_COMPAT + bool "compatibility to 0.1 series network protocol" + depends on MARS + default y + ---help--- + TRANSITIONAL: this is only needed for _mixed_ operations of the + MARS Light 0.1 kernel modules and 0.2 module. + Typically, you will need this only during upgrade for minimizig + downtime (e.g. first upgrade secondary side, then handover, + and finally upgrade the former primary side). + This option will be removed for 0.3 and later stable + series, since you will no longer need it. + +config MARS_LOGDIR + string "absolute path to the logging directory" + depends on MARS + default "/mars" + ---help--- + Path to the directory where all MARS messages will reside. + Usually this is equal to the global /mars directory. + + Logfiles and status files obey the following naming conventions: + 0.debug.log + 1.info.log + 2.warn.log + 3.error.log + 4.fatal.log + 5.total.log + Logfiles must already exist in order to be appended. + Logiles can be rotated by renaming them and creating + a new empty file in place of the old one. + + Status files follow the same rules, but .log is replaced + by .status, and they are created automatically. Their content + is however limited to a few seconds or minutes. + + Leave this at the default unless you know what you are doing. + +config MARS_MIN_SPACE_4 + int "absolutely necessary free space in /mars/ (hard limit in GB)" + depends on MARS + default 2 + ---help--- + HARDEST EMERGENCY LIMIT + + When free space in /mars/ drops under this limit, + transaction logging to /mars/ will stop at all, + even at all primary resources. All IO will directly go to the + underlying raw devices. The transaction logfile sequence numbers + will be disrupted, deliberately leaving holes in the sequence. + + This is a last-resort desperate action of the kernel. + + As a consequence, all secodaries will have no chance to + replay at that gap, even if they got the logfiles. + The secondaries will stop at the gap, left in an outdated, + but logically consistent state. + + After the problem has been fixed, the secondaries must + start a full-sync in order to continue replication at the + recent state. + + This is the hardest measure the kernel can take in order + to TRY to continue undisrupted operation at the primary side. + + In general, you should avoid such situations at the admin level. + + Please implement your own monitoring at the admin level, + which warns you and/or takes appropriate countermeasures + much earlier. + + Never rely on this emergency feature! + +config MARS_MIN_SPACE_3 + int "free space in /mars/ for primary logfiles (additional limit in GB)" + depends on MARS + default 2 + ---help--- + MEDIUM EMERGENCY LIMIT + + When free space in /mars/ drops under + MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3, + elder transaction logfiles will be deleted at primary resources. + + As a consequence, the secondaries may no longer be able to + get a consecute series of copies of logfiles. + As a result, they may get stuck somewhere inbetween at an + outdated, but logically consistent state. + + This is a desperate action of the kernel. + + After the problem has been fixed, some secondaries may need to + start a full-sync in order to continue replication at the + recent state. + + In general, you should avoid such situations at the admin level. + + Please implement your own monitoring at the admin level, + which warns you and/or takes appropriate countermeasures + much earlier. + + Never rely on this emergency feature! + +config MARS_MIN_SPACE_2 + int "free space in /mars/ for secondary logfiles (additional limit in GB)" + depends on MARS + default 2 + ---help--- + MEDIUM EMERGENCY LIMIT + + When free space in /mars/ drops under + MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2, + elder transaction logfiles will be deleted at secondary resources. + + As a consequence, some local secondary resources + may get stuck somewhere inbetween at an + outdated, but logically consistent state. + + This is a desperate action of the kernel. + + After the problem has been fixed and the free space becomes + larger than MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2 + + MARS_MIN_SPACE_2, the secondary tries to fetch the missing + logfiles from the primary again. + + However, if the necessary logfiles have been deleted at the + primary side in the meantime, this may fail. + + In general, you should avoid such situations at the admin level. + + Please implement your own monitoring at the admin level, + which warns you and/or takes appropriate countermeasures + much earlier. + + Never rely on this emergency feature! + +config MARS_MIN_SPACE_1 + int "free space in /mars/ for replication (additional limit in GB)" + depends on MARS + default 2 + ---help--- + LOWEST EMERGENCY LIMIT + + When free space in /mars/ drops under MARS_MIN_SPACE_4 + + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2 + MARS_MIN_SPACE_1, + fetching of transaction logfiles will stop at local secondary + resources. + + As a consequence, some local secondary resources + may get stuck somewhere inbetween at an + outdated, but logically consistent state. + + This is a desperate action of the kernel. + + After the problem has been fixed and the free space becomes + larger than MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2 + + MARS_MIN_SPACE_2, the secondary will continue fetching its + copy of logfiles from the primary side. + + In general, you should avoid such situations at the admin level. + + Please implement your own monitoring at the admin level, + which warns you and/or takes appropriate countermeasures + much earlier. + + Never rely on this emergency feature! + +config MARS_MIN_SPACE_0 + int "total space needed in /mars/ for (additional limit in GB)" + depends on MARS + default 12 + ---help--- + Operational pre-requirement. + + In order to use MARS, the total space available in /mars/ must + be at least MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2 + + MARS_MIN_SPACE_1 + MARS_MIN_SPACE_0. + + If you cannot afford that amount of storage space, please use + DRBD in place of MARS. -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
