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/dst/Kconfig"
|
||||
|
||||
endif # !STAGING_EXCLUDE_BUILD
|
||||
endif # STAGING
|
||||
|
|
|
@ -29,3 +29,4 @@ obj-$(CONFIG_INPUT_MIMIO) += mimio/
|
|||
obj-$(CONFIG_TRANZPORT) += frontier/
|
||||
obj-$(CONFIG_EPL) += epl/
|
||||
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