aboutsummaryrefslogtreecommitdiff
path: root/drivers/staging/dst/Kconfig
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/staging/dst/Kconfig')
-rw-r--r--drivers/staging/dst/Kconfig67
1 files changed, 0 insertions, 67 deletions
diff --git a/drivers/staging/dst/Kconfig b/drivers/staging/dst/Kconfig
deleted file mode 100644
index 448d342ac2a..00000000000
--- a/drivers/staging/dst/Kconfig
+++ /dev/null
@@ -1,67 +0,0 @@
-config DST
- tristate "Distributed storage"
- depends on NET && CRYPTO && SYSFS && BLK_DEV
- select CONNECTOR
- ---help---
- DST is a network block device storage, which can be used to organize
- exported storage 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, which allows to pass through firewalls and
- create remote backup storage in a 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 performance by
- eliminating unneded data copies and by not depending 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 complete 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 enable HEAVY debugging of the DST.
- Turn it on ONLY if you have to debug some really obscure problem.