mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-27 19:29:37 +00:00
Staging: dst: kconfig and makefile changes.
Signed-off-by: Evgeniy Polaykov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
parent
fdc4f2e95d
commit
9539bec7b7
4 changed files with 77 additions and 0 deletions
|
@ -93,5 +93,7 @@ source "drivers/staging/epl/Kconfig"
|
||||||
|
|
||||||
source "drivers/staging/android/Kconfig"
|
source "drivers/staging/android/Kconfig"
|
||||||
|
|
||||||
|
source "drivers/staging/dst/Kconfig"
|
||||||
|
|
||||||
endif # !STAGING_EXCLUDE_BUILD
|
endif # !STAGING_EXCLUDE_BUILD
|
||||||
endif # STAGING
|
endif # STAGING
|
||||||
|
|
|
@ -29,3 +29,4 @@ obj-$(CONFIG_INPUT_MIMIO) += mimio/
|
||||||
obj-$(CONFIG_TRANZPORT) += frontier/
|
obj-$(CONFIG_TRANZPORT) += frontier/
|
||||||
obj-$(CONFIG_EPL) += epl/
|
obj-$(CONFIG_EPL) += epl/
|
||||||
obj-$(CONFIG_ANDROID) += android/
|
obj-$(CONFIG_ANDROID) += android/
|
||||||
|
obj-$(CONFIG_DST) += dst/
|
||||||
|
|
71
drivers/staging/dst/Kconfig
Normal file
71
drivers/staging/dst/Kconfig
Normal file
|
@ -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.
|
3
drivers/staging/dst/Makefile
Normal file
3
drivers/staging/dst/Makefile
Normal file
|
@ -0,0 +1,3 @@
|
||||||
|
obj-$(CONFIG_DST) += nst.o
|
||||||
|
|
||||||
|
nst-y := dcore.o state.o export.o thread_pool.o crypto.o trans.o
|
Loading…
Reference in a new issue