Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 141295
b: refs/heads/master
c: 9539bec
h: refs/heads/master
i:
  141293: 1c61e88
  141291: 09f06a5
  141287: bbc939c
  141279: 4b61eb6
v: v3
  • Loading branch information
Evgeniy Polyakov authored and Greg Kroah-Hartman committed Apr 3, 2009
1 parent 86d0ea1 commit cfc5b8f
Show file tree
Hide file tree
Showing 5 changed files with 78 additions and 1 deletion.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: fdc4f2e95d3eb5c25fea449804e9174dd2e50903
refs/heads/master: 9539bec7b755f2093192410768119627079a06ec
2 changes: 2 additions & 0 deletions trunk/drivers/staging/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -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
1 change: 1 addition & 0 deletions trunk/drivers/staging/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -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 changes: 71 additions & 0 deletions trunk/drivers/staging/dst/Kconfig
Original file line number Diff line number Diff line change
@@ -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 changes: 3 additions & 0 deletions trunk/drivers/staging/dst/Makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
obj-$(CONFIG_DST) += nst.o

nst-y := dcore.o state.o export.o thread_pool.o crypto.o trans.o

0 comments on commit cfc5b8f

Please sign in to comment.