aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/staging/dst
diff options
context:
space:
mode:
authorEvgeniy Polyakov <zbr@ioremap.net>2009-01-14 02:05:33 +0300
committerGreg Kroah-Hartman <gregkh@suse.de>2009-04-03 14:53:32 -0700
commit9539bec7b755f2093192410768119627079a06ec (patch)
tree61b3fd2d4fd83ad347c515739f35b8d7f488fec2 /drivers/staging/dst
parentstaging: dst: replace bus_id with dev_set_name (diff)
downloadlinux-dev-9539bec7b755f2093192410768119627079a06ec.tar.xz
linux-dev-9539bec7b755f2093192410768119627079a06ec.zip
Staging: dst: kconfig and makefile changes.
Signed-off-by: Evgeniy Polaykov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/staging/dst')
-rw-r--r--drivers/staging/dst/Kconfig71
-rw-r--r--drivers/staging/dst/Makefile3
2 files changed, 74 insertions, 0 deletions
diff --git a/drivers/staging/dst/Kconfig b/drivers/staging/dst/Kconfig
new file mode 100644
index 000000000000..12ffa37aad3d
--- /dev/null
+++ b/drivers/staging/dst/Kconfig
@@ -0,0 +1,71 @@
+config DST
+ tristate "Distributed storage"
+ depends on NET && CRYPTO && SYSFS
+ select CONNECTOR
+ select LIBCRC32C
+ ---help---
+ DST is a network block device storage, which can be used to organize
+ exported storages on the remote nodes into the local block device.
+
+ DST is a network block device storage, which can be used to organize
+ exported storages on the remote nodes into the local block device.
+
+ DST works on top of any network media and protocol, it is just a matter
+ of configuration utility to understand the correct addresses. The most
+ common example is TCP over IP allows to pass through firewalls and
+ created remote backup storage in the different datacenter. DST requires
+ single port to be enabled on the exporting node and outgoing connections
+ on the local node.
+
+ DST works with in-kernel client and server, which improves the performance
+ eliminating unneded data copies and allows not to depend on the version
+ of the external IO components. It requires userspace configuration utility
+ though.
+
+ DST uses transaction model, when each store has to be explicitly acked
+ from the remote node to be considered as successfully written. There
+ may be lots of in-flight transactions. When remote host does not ack
+ the transaction it will be resent predefined number of times with specified
+ timeouts between them. All those parameters are configurable. Transactions
+ are marked as failed after all resends completed unsuccessfully, having
+ long enough resend timeout and/or large number of resends allows not to
+ return error to the higher (FS usually) layer in case of short network
+ problems or remote node outages. In case of network RAID setup this means
+ that storage will not degrade until transactions are marked as failed, and
+ thus will not force checksum recalculation and data rebuild. In case of
+ connection failure DST will try to reconnect to the remote node automatically.
+ DST sends ping commands at idle time to detect if remote node is alive.
+
+ Because of transactional model it is possible to use zero-copy sending
+ without worry of data corruption (which in turn could be detected by the
+ strong checksums though).
+
+ DST may fully encrypt the data channel in case of untrusted channel and implement
+ strong checksum of the transferred data. It is possible to configure algorithms
+ and crypto keys, they should match on both sides of the network channel.
+ Crypto processing does not introduce noticeble performance overhead, since DST
+ uses configurable pool of threads to perform crypto processing.
+
+ DST utilizes memory pool model of all its transaction allocations (it is the
+ only additional allocation on the client) and server allocations (bio pools,
+ while pages are allocated from the slab).
+
+ At startup DST performs a simple negotiation with the export node to determine
+ access permissions and size of the exported storage. It can be extended if
+ new parameters should be autonegotiated.
+
+ DST carries block IO flags in the protocol, which allows to transparently implement
+ barriers and sync/flush operations. Those flags are used in the export node where
+ IO against the local storage is performed, which means that sync write will be sync
+ on the remote node too, which in turn improves data integrity and improved resistance
+ to errors and data corruption during power outages or storage damages.
+
+ Homepage: http://www.ioremap.net/projects/dst
+ Userspace configuration utility and the latest releases: http://www.ioremap.net/archive/dst/
+
+config DST_DEBUG
+ bool "DST debug"
+ depends on DST
+ ---help---
+ This option will turn HEAVY debugging of the DST.
+ Turn it on ONLY if you have to debug some really obscure problem.
diff --git a/drivers/staging/dst/Makefile b/drivers/staging/dst/Makefile
new file mode 100644
index 000000000000..3a8b0cf9643e
--- /dev/null
+++ b/drivers/staging/dst/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DST) += nst.o
+
+nst-y := dcore.o state.o export.o thread_pool.o crypto.o trans.o