mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <zbr@ioremap.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Evgeniy Polaykov <zbr@ioremap.net>
Subject: [7/7] dst: kconfig and makefile changes.
Date: Wed, 17 Dec 2008 16:53:18 +0300	[thread overview]
Message-ID: <1229521998-7870-8-git-send-email-zbr@ioremap.net> (raw)
In-Reply-To: <1229521998-7870-7-git-send-email-zbr@ioremap.net>

Signed-off-by: Evgeniy Polaykov <zbr@ioremap.net>

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 61ad8d6..2a92cd8 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -445,4 +445,6 @@ config BLK_DEV_HD
 
 	  If unsure, say N.
 
+source "drivers/block/dst/Kconfig"
+
 endif # BLK_DEV
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 204332b..6400de0 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -32,3 +32,5 @@ obj-$(CONFIG_BLK_DEV_UB)	+= ub.o
 obj-$(CONFIG_BLK_DEV_HD)	+= hd.o
 
 obj-$(CONFIG_XEN_BLKDEV_FRONTEND)	+= xen-blkfront.o
+
+obj-$(CONFIG_DST)	+= dst/
diff --git a/drivers/block/dst/Kconfig b/drivers/block/dst/Kconfig
new file mode 100644
index 0000000..12ffa37
--- /dev/null
+++ b/drivers/block/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/block/dst/Makefile b/drivers/block/dst/Makefile
new file mode 100644
index 0000000..3a8b0cf
--- /dev/null
+++ b/drivers/block/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

  reply	other threads:[~2008-12-17 13:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 13:53 [0/7] dst: new release introduction Evgeniy Polyakov
2008-12-17 13:53 ` [1/7] dst: core files Evgeniy Polyakov
2008-12-17 13:53   ` [2/7] dst: network state machine Evgeniy Polyakov
2008-12-17 13:53     ` [3/7] dst: export node Evgeniy Polyakov
2008-12-17 13:53       ` [4/7] dst: thread pool Evgeniy Polyakov
2008-12-17 13:53         ` [5/7] dst: transactions Evgeniy Polyakov
2008-12-17 13:53           ` [6/7] dst: crypto processing Evgeniy Polyakov
2008-12-17 13:53             ` Evgeniy Polyakov [this message]
2008-12-17 15:55         ` [4/7] dst: thread pool Arnd Bergmann
2008-12-17 20:03           ` Benjamin Herrenschmidt
2008-12-17 23:32             ` Evgeniy Polyakov
2008-12-18  0:51               ` Benjamin Herrenschmidt
2008-12-18  8:10                 ` Evgeniy Polyakov
2008-12-18  9:44                   ` Arnd Bergmann
2008-12-17 23:39           ` Evgeniy Polyakov
2008-12-26 11:56 [0/7] Distributed storage release Evgeniy Polyakov
2008-12-26 11:56 ` [1/7] dst: core files Evgeniy Polyakov
2008-12-26 11:56   ` [2/7] dst: network state machine Evgeniy Polyakov
2008-12-26 11:56     ` [3/7] dst: export node Evgeniy Polyakov
2008-12-26 11:56       ` [4/7] dst: thread pool Evgeniy Polyakov
2008-12-26 11:56         ` [5/7] dst: transactions Evgeniy Polyakov
2008-12-26 11:56           ` [6/7] dst: crypto processing Evgeniy Polyakov
2008-12-26 11:56             ` [7/7] dst: kconfig and makefile changes Evgeniy Polyakov
2008-12-30 17:26               ` Randy Dunlap
2008-12-30 21:21                 ` Evgeniy Polyakov
2009-01-13 23:05 [0/7] Distributed storage for drivers/staging merge request Evgeniy Polyakov
2009-01-13 23:05 ` [1/7] dst: core files Evgeniy Polyakov
2009-01-13 23:05   ` [2/7] dst: network state machine Evgeniy Polyakov
2009-01-13 23:05     ` [3/7] dst: export node Evgeniy Polyakov
2009-01-13 23:05       ` [4/7] dst: thread pool Evgeniy Polyakov
2009-01-13 23:05         ` [5/7] dst: transactions Evgeniy Polyakov
2009-01-13 23:05           ` [6/7] dst: crypto processing Evgeniy Polyakov
2009-01-13 23:05             ` [7/7] dst: kconfig and makefile changes Evgeniy Polyakov
2009-01-14  2:22               ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1229521998-7870-8-git-send-email-zbr@ioremap.net \
    --to=zbr@ioremap.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®