#
# MARS configuration
#

config MARS
	tristate "storage system MARS (EXPERIMENTAL)"
	depends on BLOCK && HIGH_RES_TIMERS
	default n
	---help---
	Experimental storage System. Only compile as a module!

config MARS_DEBUG
	bool "enable runtime checks in MARS"
	depends on MARS
	default n
	---help---
	OFF for production systems. ON for testing!

config MARS_BIGMODULE
	tristate "compile all MARS modules into a single kernel module"
	depends on MARS
	default m
	select MARS_HAVE_BIGMODULE
	---help---
	Normally ON. Switch off only for EXPERIMENTS!

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 compiletime constant.

config MARS_MEM_RETRY
	bool "make MARS memory allocation more robust"
	depends on MARS
	default y
	---help---
	Normally ON. Switch only off for systems having very low memory.

config MARS_LOGFILE
	string "full path to the logfile"
	depends on MARS
	default "/mars/log.txt"
	---help---
	Path to the logfile where all MARS messages go to.
	The logfile 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.
	When none exists, messages are either reported to syslog when
	CONFIG_MARS_USE_SYSLOG	is set, or else MARS will be qiet.

config MARS_USE_SYSLOG
	bool "use syslog for messages"
	depends on MARS
	default n
	---help---
	Normally OFF.
	When switched on (and no logfile exists), the syslog
	may get flooded by printk() messages, leading to performance
	problems if remote syslog forwarding is enabled (and possibly
	in other cases). Thus we recommend to prefer file logging.
	When this option is off, the logfile will be used (if one exists).

config MARS_SCAN_INTERVAL
	int "re-scanning of symlinks in /mars/ (in seconds)"
	depends on MARS
	default 5
	---help---
	May influence the system load; dont use too low nubmers.

config MARS_PROPAGATE_INTERVAL
	int "network propagation delay of changes in /mars/ (in seconds)"
	depends on MARS
	default 5
	---help---
	May influence the system load; dont use too low nubmers.

config MARS_SYNC_FLIP_INTERVAL
	int "interrpt sync by logfile update after (seconds)"
	depends on MARS
	default 60
	---help---
	0 = OFF. Normally ON.
	When disabled, application of logfiles may wait for
	a very time, until full sync has finished. As a
	consequence, your /mars/ filesystem may run out
	of space. When enabled, the applied logfiles can
	be deleted, freeing space on /mars/. Therefore,
	will usually want this. However, you may increase
	the time interval to increase throughput in favour
	of latency.

config MARS_FAST_TRIGGER
	bool "fast internal triggering"
	depends on MARS
	default y
	---help---
	Normally ON. Switch off in case of endless trigger loops

config MARS_NETIO_TIMEOUT
	int "timeout for remote IO operations (in seconds)"
	depends on MARS
	default 30
	---help---
	In case of network hangs, don't wait forever, but rather
	abort with -ENOTCONN
	when == 0, wait forever (may lead to hanging operations
	similar to NFS hard mounts)

config MARS_MEM_PREALLOC
	bool "avoid memory fragmentation by preallocation"
	depends on MARS
	default y
	---help---
	Normally ON. Switch off only for EXPERIMENTS!

config MARS_FAST_FULLSYNC
	bool "decrease network traffic at initial sync"
	depends on MARS
	default y
	---help---
	Normally ON.
	When on, both sides will read the data, compute a md5
	checksum, and compare them. Only in case the checksum
	mismatches, the data will be actually transferred over
	the network. This may increase the IO traffic in favour
	of network traffic. Usually it does no harm to re-read
	the same data twice (only in case of mismatches) over bio
	because RAID controllers will usually cache their data
	for some time. In case of buffered aio reads from filesystems,
	the data is cached by the kernel anyway.

config MARS_LOADAVG_LIMIT
	bool "stall copy traffic when loadavg gets too high"
	depends on MARS
	default y
	---help---
	Normally ON.

config MARS_LINEAR_CACHE_SIZE
	int "cache size for linear scans of logfiles (in MB)"
	depends on MARS
	default 64
	---help---
	Setting this to high numbers (or disabling by setting to 0)
	may disturb the application performance, because MARS will
	pollute the page cache with pages from the MARS logfiles.
	Setting this to low numbers will prevent such a pollution,
	at the cost of (sometimes) more IO operations.
	EXCEPTION: when you run MARS on a standalone storage server
	(e.g. exporting devices via iSCSI), you should use high numbers
	here or even disable this feature. THEN (and ONLY THEN)
	you want MARS to use all the memory for its own caching,
	since there is no other application competing for main memory.
	In unsure, take the default of 64.

#config MARS_HUNG
#	bool "hangup on kernel stacktrace (EXPERIMENTAL!!!)"
#	depends on MARS && MARS_BIGMODULE!=m
#	default n
#	---help---
#	Normally OFF. Switch on only for EXPERIMENTS!

config MARS_LOGROT
	bool "allow logrotate during operation"
	depends on MARS
	default y
	---help---
	Normally ON. Switch off only for EXPERIMENTS!

config MARS_LOGROT_AUTO
	int "automatic logrotate when logfile exceeds size (in GB)"
	depends on MARS_LOGROT
	default 32
	---help---
	You could switch this off by setting to 0. However, deletion
	of really huge logfile can take several minutes, or even substantial
	fractions of hours (depending on the underlying filesystem).
	Thus it is highly recommended to limit the logfile size to some
	reasonable maximum size. Switch only off for experiments!

config MARS_MIN_SPACE
	bool "check for filesystem overflow in /mars"
	depends on MARS
	default y
	---help---
	Normally ON. Switch off only for EXPERIMENTS!

config MARS_MIN_SPACE_BASE
	int "free space in /mars/ (hard limit in gigabytes)"
	depends on MARS_MIN_SPACE
	default 8
	---help---
	when this limit is exceeded, transaction logging to /mars/
	will stop. This affects not only write IO to /dev/mars/*,
	but also logfile transfers etc. As a consequence, writes
	on the primary will directly go to the device, and the secondaries
	will be outdated.
	In order to retain full operations, you _need_ to implement
	your own monitoring which _must_ warn you long before this
	hard limit catches you. If it already has caught you, it
	will be too late: you have to recover by hand, e.g. by
	starting a full sync.

config MARS_MIN_SPACE_PERCENT
	int "free space in /mars/ (hard limit in percent)"
	depends on MARS_MIN_SPACE
	default 0
	---help---
	this limit is in addition to CONFIG_MARS_MIN_SPACE_BASE.

config MARS_LOGDELETE_AUTO
	int "automatic log-delete when space in /mars/ gets short (in GB)"
	depends on MARS_MIN_SPACE
	default 8
	---help---
	This limit is in addition to CONFIG_MARS_MIN_SPACE_BASE
	and CONFIG_MARS_MIN_SPACE_PERCENT.
	You can switch this off by setting to 0.
	When the limit is hit, MARS tries to delete the eldest logfile,
	when possible, in order to free some space.
	Notice: deleting logfiles on a primary which have not yet
	been transferred to some secondary is possible, but as a
	consequence the secondary may need a full-sync afterwards.

config MARS_PREFER_SIO
	bool "prefer sio bricks instead of aio"
	depends on MARS
	default n
	---help---
	Normally OFF for production systems.
	Only use as alternative for testing.

##### mostly obsolete

config MARS_DUMMY
	tristate "MARS dummy brick"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_CHECK
	tristate "MARS check brick"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_IF
	tristate "interface to a linux device"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_BIO
	tristate "interface to blkdev via kernel BIO"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_AIO
	tristate "interface to a linux file (Asynchronous IO)"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_SIO
	tristate "interface to a linux file, synchronous (currently unused)"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_BUF
	tristate "buffer brick (currently unused)"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_USEBUF
	tristate "usebuf brick (currently unused)"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_TRANS_LOGGER
	tristate "transaction logger"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_SERVER
	tristate "server brick"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_CLIENT
	tristate "client brick"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_COPY
	tristate "copy brick"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

config MARS_LIGHT
	tristate "MARS Light main (protoype, will be replaced)"
	depends on MARS && MARS_BIGMODULE!=m
	default m
	---help---
	Experimental storage System.

# the following is used as an internal proprocessor symbol

config MARS_HAVE_BIGMODULE
	bool