Bug#770247: RFP: mars-dkms -- Asynchronous Block-Level Storage Replication
On Thu, 20 Nov 2014 11:44:45 +1100
Dmitry Smirnov <onlyjob@debian.org> wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> Package name: mars-dkms
> Version: 0.1.09
> Upstream Author: Thomas Schoebel-Theuer <tst@1und1.de>
> URL: http://schoebel.github.io/mars/
> License: GPL-2+, GFDL-1.3+
> Description: Asynchronous Block-Level Storage Replication
> MARS can be used to replicate Linux-based storage devices, or even
> whole datacenters, over arbitrary distances (geo-redundancy).
> .
> Main features:
> .
> Anytime Consistency
> Arbitrary Distances
> Tolerates Flaky Networks
> .
> MARS Light is almost a drop-in replacement for DRBD (block-level
> storage replication). It runs as a Linux kernel module.
> .
> In contrast to plain DRBD, it works asynchronously and over arbitrary
> distances.
Note that the user reading this description need not be familiar with
DRBD to understand it. Hence I would reverse this sentence to produce
something like
MARS Light is a block-level storage replication solution implemented
in the form of a Linux kernel module.
.
It's almost a drop-in replacement for DRBD but it works
asynchronously and over arbitrary distances.
> Our internal 1&1 testing runs between datacenters in the
> US and Europe. MARS uses very different technology under the hood,
> similar to transaction logging of database systems.
When a user reads the package description, "our" is a moot term for
them at that time; at best, it would mean "Debian" which is clearly not
true. Hence I'd refactor the long description making it as much neutral
as possible, refining the above to become
MARS Light is a block-level storage replication solution implemented
in the form of a Linux kernel module.
.
It's almost a drop-in replacement for DRBD but it works
asynchronously and over arbitrary distances using a technology
similar to transaction logging of database systems.
> Reliability: application and replication are completely decoupled.
> Networking problems (e.g. packet loss, bottlenecks) have no impact
> onto your application at the primary side.
> .
> Anytime Consistency: on a secondary node, its version of the
> underlying disk device is always consistent in itself, but may be
> outdated (represent a former state from the primary side). Thanks to
> incremental replication of the transaction logfiles, usually the
> lag-behind will be only a few seconds, or parts of a second.
> .
These two paragraphs sound OK if a bit too long.
> Synchronous or near-synchronous operating modes are planned for the
> future, but are expected to work reliably only over short distances
> (less than 50km), due to fundamental properties of distributed
> systems.
I would remove this one: something which is planned is okay for an
advertisement brief, not a package description.
Reply to: